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RASTER  GRAPHICS  EXTENSIONS  TO  THE 
GRAPHICS  COMPATIBILITY  SYSTEM  (GCS) 


PART  I:  HOW  TO  INTEGRATE  RASTER 
GRAPHICS  CONCEPTS  INTO  GCS 


I.  Introduction 

The  3D  version  of  the  Graphics  Compatibility  System 
(GCS-3D)  contains  several  basic  concepts  that  allow  GCS 
to  be  expanded  to  deal  with  raster  graphics.  The  most  impor- 
tant capability  that  a raster  graphics  system  has,  that  a 
line  drawing  system  does  not,  is  the  ability  to  display  a 
polygon  as  a filled  in  area  of  color.  This  leads  to  a new 
problem,  namely:  when  two  polygons  overlap  on  the  screen  one 
of  them  must  obscure  the  other.  Therefore,  a method  such  as 
a hidden  surface  algorithm  is  required  to  display  pictures  in 
a consistent,  controllable  way.  The  3d  data  structure  already 
in-use  by  GCS-3D  makes  this  extension  possible  without  a major 
revision  of  the  system. 

To  access  some  capabilities  of  raster  systems,  either  new 
or  expanded  concepts  must  be  added  to  a line  oriented  graphics 
package.  Some  examples  are:  images  made  of  colored  pixels, 
shaded  polygons,  direct  view  surface  pixel  operations,  etc. 

These  can  only  be  implemented  by  new  sets  of  subroutines  and 
options. 

The  basic  set  of  concepts  present  in  GCS-3D  can  also  be 
found  in  the  original  CORE  Graphics  System.  Virtually  all  the 
additions  required  to  extend  one  system  for  raster  graphics 
can  be  directly  applied  to  the  other.  Two  extensive  documents, 
already  written  by  our  group,  will  serve  as  detailed  references: 
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Raster  Graphics  Extensions  to  the  Core  Graphics  System 

Reference  Manual:  Raster  Graphics  Extensions  to  the  Core 
System. 

These  documents  are  included  as  part  of  this  report. 
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2.  Hidden  Surfaces 


As  noted  earlier,  to  determine  which  of  two  overlapping 
polygons  obscures  the  other,  one  must  consider  depth  information 
about  each  polygon.  Within  a single  window  this  information 
is  just  the  distance  from  the  observer  to  the  polygon  in 
virtual  world  coordinates.  However,  when  several  different 
windows  are  displayed  in  different  viewport  areas  on  the 
screen,  a more  sophisticated  way  of  relating  depth  information 
about  polygons  in  the  windows  is  required.  Three  dimensional 
device  viewports  are  quite  convenient  for  resolving  this 
problem.  Each  user  3D  window  is  mapped  into  a 3D  device 
viewport,  so  that  a particular  polygon  in  the  virtual  world 
occupies  a specific  location  in  3D  device  space.  The  location 
in  device  space  is  then  used  to  define  the  depth  of  the  polygon 
when  the  hidden  surface  algorithm  is  applied. 

Using  this  approach  there  are  several  ways  of  controlling 
which  of  two  polygons  obscures  the  other  one.  A simple  depth 
priority  system  can  be  constructed  by  keeping  polygons  in  planes 
normal  to  the  Z axis.  Then  all  points  on  an  object  are  at  the 
same  depth  from  the  observer.  This  is  called  2^0.  It  simplifies 
a hidden  surface  algorithm  into  a simple  depth  sort.  One  way 
to  achieve  this  priority  between  two  windows  is  to  place  each 
into  a flat  (in  the  Z dimension)  plane  with  one  plane  in  front 
of  the  other.  An  even  simpler  method  of  making  one  polygon 
overwrite  another  is  to  place  both  polygons  on  the  same  depth 
plane.  Then  the  only  way  to  determine  which  is  the  obscuring 
polygon  is  with  temporal  priority  (the  second  overwrites  the 
first)  . 
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GCS-3D  already  has  the  concepts  of  3D  device  space  and 
3D  device  viewports  (see  the  GCS  subroutine  U3AREA)  and  a 
3D  data  structure  to  support  these  notions  for  hidden  surface 
algorithms  and  2>sD  depth  priority.  Therefore  no  additional 
concepts  or  functions  need  be  added  to  GCS-3D  to  deal  with 
hidden  surfaces. 
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3.  Polygons 

A fundamental  concept  for  raster  graphics  is  the  polygon 
that  is  filled  in  with  color.*  A polygon  is  specified  by  two 
types  of  information.  First,  the  way  in  which  the  polygon  will 
be  colored  is  described,  then  the  location  of  the  polygon's 
vertices  in  virtual  world  coordinates  (in  either  2D  or  3D)  must 
be  given. 

In  the  raster  extension  to  the  CORE  system  there  are  three 
different  types  of  colored  polygon,  namely:  plain,  painted, 
and  shaded.  The  plain  type  is  simply  a polygon  filled  with 
a constant  color  or  gray  scale  intensity  over  its  entire  surface. 
The  cclor/intensity  of  the  polygon  is  the  current  color/intensity 
attribute  in  effect  when  the  polygon  primitive  is  defined. 

A painted  polygon  is  filled  with  an  image  made  up  of 
differently  colored  pixels.  The  polygon's  image  is  defined  by 
the  user  as  a large  rectangular  array  containing  color/ intensity 
values.  The  user  then  specifies  the  exact  portion  of  the 
image's  pixel  array  to  be  placed  in  the  polygon  (see  the  CORE 
reference  manual  for  the  specifics  of  the  process) . Once  a 
painted  polygon  is  described  it  can  be  viewed  from  any  location 
in  virtual  world  space  and  the  image  on  its  surface  will  appear 
properly  transformed.  This  is  analogous  to  viewing  a picture 
on  the  wall  from  different  anqles  and  having  it  still  look 
correct. 

A shaded  polygon  may  have  a different  color  specified  at 

each  of  its  vertices.  It  is  then  filled  by  linearly  interpolating 

7 This  is  not  the  outline  of  a regular  polygon,  drawn  by  the 
GCS  subroutine  UPLYGN.  Such  polygons  could  be  built  on  top  of  the 
basic  polygon  primitive  described  in  this  section. 
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between  the  colors  specified  at  each  vertex  (GOURAUD  shading) . 

This  is  quite  useful  for  depicting  continuously  varying  colors 
or  shaded  objects. 

In  keeping  with  the  general  method  used  by  GCS-3D  for 

. 

passing  arguments  in  subroutine  calls,  the  three  polygon  types 
are  new  options  that  belong  to  the  USET  subroutines.  The  set 
of  subroutines  added  to  the  CORE  system  to  complete  the  descrip- 
tion of  these  various  polygons  must  also  be  added  to  GCS-3D. 

The  plain  polygon  needs  a comprehensive  way  of  specifying 
its  color  (see  section  6) . 

A painted  polygon  requires  the  following:  a pixel  array 

or  file  to  store  its  image  in.  The  CORE  uses  the  functions: 

SET_PIXEL_ARRAY (COLUMNS , ROW, ARRAY) 

SET_FIXEL_FILE (COLUMNS , ROWS , FILE_NAME) 

The  format  of  this  file  or  array  must  be  given,  see: 

SET_P IXEL_ARRAY_FORMAT ( B ITS_PER_P IXEL , 

BITS_PER_PACKING_UNIT,PIXELS_PER_UNIT) 

And  a way  to  specify  the  region  of  the  image  that  should  be 

used  to  fill  the  polygon,  see: 

SET_PIXEL_ARRAY_EXTENT (X_LENGTH , Y_LENGTH ) 

SET_VERTEX_MAP (VERTEX_INDEX_ARRAY , X_MAP , Y_MAP) 

A shaded  polygon  needs  a way  to  define  the  color/intensity 

at  each  vertex:  see  the  SET_VERTEX_COLORS  functions. 

Finally,  the  description  of  a polygon  (of  any  type)  is 

completed  by  giving  its  vertex  list  in  either  2D  or  3D  virtual 

world  coordinates:  see  the  POLYGON  fucntions  in  the  CORE  raster 

I 

extensions. 
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4.  Polygon  Meshes 


Often  instead  of  dealing  with  a single  polygon  at  a time 
it  is  more  convenient  and  efficient  to  deal  with  a set  of 
connected  polygons  called  a mesh.  Since  several  polygons  in 
a mesh  may  share  the  same  vertex,  it  is  convenient' to  give  the 

9 

entire  vertex  list  of  the  mesh  at  one  time.  Then  a polygon 
element  of  the  mesh  is  defined  by  ind  xing  a subset  of  these 
vertices.  This  saves  storage  space  and  gives  information  about 
which  polygons  share  common  vertices  or  edges . 

To  further  improve  the  way  polygon  meshes  are  handled, 
three  different  types  of  meshes  can  be  specified:  a mesh 
that  does  not  form  a closed  polyhydra,  a closed  convex  polvhvdra, 
and  a closed  concave  polyhydra.  These  are  referred  to  as  the 
shape  of  the  mesh  in  the  CORE  system. 

If  GCS-3D  is  going  to  deal  with  polygon  meshes  it  needs 
a subroutine  call  like  the  ?OLYGON_MESH  functions  in  the  CORE 
System,  tc  pass  the  entire  vertex  list  and  define  the  beginning 
of  a mesh.  It  also  should  have  a subroutine  that  designates  a 
particular  polygonal  element  in  the  mesh,  such  as: 

POLYGON_EDGE_LIST (VERTEX_INDEX_ARRAY ,N) 

The  shape  attribute  of  a mesh  could  easily  be  included  as  a 
new  group  of  USET  options. 
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5.  Colors  and  Intensities 


Because  of  the  need  to  precisely  control  the  color  and 
intensity  in  raster  graphics,  most  raster  Systems  have  a greater 
range  of  colors  and  intensities  than  do  vector  systems.  Therefore, 
the  ways  to  specify  colors  and  intensities  need  to-be  expanded 
in  GCS . 

In  the  Core  System  the  color  attribute  (a  parallel  set 
of  capabilities  for  the  intensity  attribute  also  exists)  is 
specified  in  two  ways:  by  value  and  by  index.  In  the  first 
way,  the  color  attribute  is  specified  by  Red,  Green,  and  Blue 
primaries,  if  the  exact  (R,G,B)  triplet  specified  is  not  in 
the  active  color  set  (set  of  colors  the  device  is  capable  of 
displaying  simultaneously)  values  are  rounded  to  the  nearest 
color  displayable  on  the  view  surface.  In  the  second  way  (by 
index) , we  can  sepcify  that  the  Ith  color/intensity  from  the 
ordered  set  of  available  colors/intensities , is  to  be  used 
as  the  color/intensity  attribute. 

The  concept  can  be  extended  to  a color  lookup  table.  A 
lookup  table  is  the  set  of  colors  that  the  display  surface 
is  capable  of  displaying  simultaneously,  and  is  a subset  of 
the  global  color  set  (all  colors  that  can  be  displayed  on  the 
display  surface) . 

To  keep  the  consistency  of  passing  arguments  for  sub- 
routine calls,  as  used  in  GCS-3D,  some  new  options  need  to 
be  introduced. 

Setting  a color  (intensity)  by  index  should  be  an  UPSET 
option.  In  order  to  allow  a means  of  expansion  beyond  the 


8 colors  (3  levels  of  intensity)  now  available  as  a USET 
option,  additional  USET  options  should  be  made  available.  To 
set  a color  or  background  color  by  value  (red,  green,  and  blue 
primaries)  GCS-3D  needs  some  new  UPSET  options,  or  a new  set 
of  subroutines  to  set  three  new  options,  one  for  each  primary 
colors. 

Setting  the  vertex  colors  or  intensities  is  basically  the 
same  as  setting  the  color  or  intensity,  but  with  a difference 
of  having  a list  of  colors  or  intensities  to  be  set  (for 
vertices  of  a shaded  polygon) . This  also  can  be  done  by  intro- 
ducing a new  set  of  subroutines  to  set  the  UPSET  options. 
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6.  Operations  on  the  View  Surface 

In  order  to  have  full  control  over  what  is  displayed  on 
a raster  screen,  the  application  programmer  should  have  direct 
access  to  the  view  surface/refresh  buffer  (some  interaction 
techniques  must  directly  modify  and  restore  portions  of  the 
refresh  buffer) . This  includes  reading  and  writing  pixels  onto 
the  screen.  This  can  be  done  either  one  pixel  at  a time,  or  a 
rectangular  portion  of  the  screen  could  be  dealt  with  as  a 
group  of  pixels.  Also,  the  user  should  be  able  to  specify 
the  different  ways  in  which  new  information  can  be  overlayed 
or.  the  screen  (setting  the  view  surface  overlay  mode)  . 

The  operations  on  the  view  surface  (see  Raster  Extensions 
to  the  Core  System,  Section  10)  introduces  new  subroutines 
for  read/v,rite  view  surface  pixel (s)  color/intensity  (read/ 
write  pixel (s)  color/intensity  of  a specified  portion  of  the 
display  surface) . 

The  concept  of  setting  the  view  surface  overlay  mode 
(how  a new  pixel  affects  the  old  pixel  on  the  view  surface. 

See  Raster  Extensions  to  the  Core  System.  Section  10.2.5), 
needs  a set  of  new  USET  options. 

Note:  Eoth  Painted  Polygons,  and  direct  view  surface 

operations  on  a group  of  Pixels  require  either  a current  pixel 
array  or  current  pixel  file.  To  pass  the  information  this 
array/file  must  itself  be  described  by  the  way  in  which  the 
pixel  color  information  is  packed. 
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In  order  that  the  application  programmer  have  full 
control  over  the  system,  and  make  the  best  use  of  it,  a set  of 
inquiry  and  redefining  functions  have  been  introduced  into 
the  Core  System.  They  should  also  be  implemented  in  the 

1 

GCS-3D  system. 

The  user  should  be  able  to  inquire:  the  current  color 
or  intensity  (by  index  or  value) , color  or  intensities  of 
vertices  of  a polygon,  total  global  colors  or  a subset  of 
it  (active  color  set/table  lookup) , pixel  array/file, 

pixel  array  format,...  (see  Raster  Extensions  to 
the  Core  System) . 

The  user  should  also  be  able  to  change  the  active  color 
table  (both  by  value,  and  by  index) . This  could  be  done  by 
REDEFINE  function  calls  (see  Raster  Extensions  to  the  Core 
System,  Section  4. 2. 1.3). 

A new  set  of  subroutines  are  needed  in  GCS-3D  for 
these  functions. 


8.  Control 

In  standard  line  drawing  systems,  output  primitives  can 
always  be  displayed  as  soon  as  they  are  defined.  But  if  we 
want  hidden  surfaces  to  be  removed  (raster  systems) , then  usually 
all  output  primitives  must  be  defined  before  the  hidden  surface 
algorithm  can  be  applied,  and  then  the  result  can  be  displayed. 
Therefore  some  control  function  is  needed  to  indicate  when  all 
output  primitives  have  been  defined,  to  initiate  the  hidden 
surface  algorithm.  The  Core  System's  Batch  of  Updates  function 
is  for  this  purpose,  and  has  two  capabilities:  initiate  a 
NEWFRAME  action  (update  the  display  surface  to  contain  only 
the  defined,  visible,  retained  segments/frames) , or  do  not 
initiate  a NEWFRAME  action. 

Hidden  Surface  Algorithms  are  expensive  (in  computer 
time) , when  applied  to  pictures  with  any  complexity.  In  order 
to  avoid  this  expense  when  doing  real  time  work,  there  should 
be  an  alternative  display  method,  and  the  user  should  be  able 
to  choose  which  display  mode  is  appropriate.  The  alternative 
is  fast  mode,  in  which  output  primitives  and  boundaries  of  the 
polygons  are  displayed  immediately,  so  the  batching  has  no 
effect,  because  the  view  surface  is  always  up  to  date.  There 
are  two  other  options,  namely,  hidden  line  mode,  and  hidden 
surface  mode.  In  either  of  these  two  modes  nothing  is  displayed 
until  the  end  of  batch  occures  (at  which  time  hidden  line  or 
surface  algorithm  is  initiated) . Both  of  these  depend  on 
Pseudo  Display  File. 

Therefore,  for  batching  of  updates  a new  subroutine  should 
be  introduced  to  optionally  initiate  a NEWFRAME  action 


. * 
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corresponsing  to  calling  UPOST.  The  NEWFRAME  would  depend  on 
the  current  setting  for  display  mode,  and  on  the  type  of  display 
device. 

Also  three  new  USET  options  should  be  introduced  to 
correspond  to  the  display  modes  (fast  mode,  hidden  line  mode,  \ 

and  hidden  surface  mode) . 
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PART  II:  RASTER  GRAPHICS  EXTENSIONS  TO  THE  CORE 
GRAPHICS  SYSTEM 


1.  Introduction 

Two  trends  in  computer  graphics  have  motivated  the  work 
reported  here.  The  first  trend  is  the  development  of  portable, 
device-independent  graphics  subroutine  packages  for  use  with 
various  line-drawing  graphics  devices,  both  passive  and  inter- 
active. This  trend  has  most  recently  focussed  on  the  Core 
Graphics  System,  a proposed  standard  graphics  package  (GSPC  77) . 
The  Core  System  appears  destined  to  become  the  basis  for  ANSI 
(national)  and  ISO  (international)  standards. 

The  second  trend  is  the  rapid  emergence  of  raster  graphics 
hardware  out  of  its  traditional  preserves  of  image  display 
and  process  control  into  the  world  of  interactive  graphics. 

This  has  occurred  because  of  rapid  change  in  the  economics  of 
large  scale  integration  and  because  of  user  demand  for  the 
color  and  shaded  areas  so  easy  to  provide  with  raster  graphics 
and  so  difficult  to  provide  with  line-drawing  graphics.  In 
many  applications,  raster  graphics  is  a very  natural  complement 
to  line-drawing  graphics,  while  in  other  applications,  raster 
graphics  will  sooner  or  later  replace  line-drawing  graphics. 
Still  other  applications,  never  considered  practical  with 
line-drawing  graphics  for  reasons  of  either  economics  or  display 
aesthetics,  suddenly  become  feasible  with  raster  graphics. 
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We  have  been  developing  standard  software  for  line-drawing 
graphics,  while  raster  graphics  grows  at  a rapid  pace.  This 
is  not  unexpected,  because  standards  must  of  necessity  lag 
the  technology.  It  was  in  recognition  of  this  necessary  lag 
and  of  the  rapid  developments  and  changes  in  raster  graphics 
that  the  charter  to  be  Core  System  developers  was  to  exclude 
consideration  of  raster  graphics 

However,  four  years  after  the  workshop  which  chartered 
and  solidified  the  graphics  standards  movement,  it  seems 
appropriate  to  extend  existing  line-drawing  graphics  packages 
to  include  raster  graphics  concepts,  so  that  the  new  technology 
can  be  gracefully  integrated  with  the  old. 
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2 . Related  Work 


Several  line-oriented  graphics  packages  with  some  raster 
graphics  capabilities  have  been  implemented  .In  all  cases,  the  basic 
intent  is  to  deal  with  computer-synthesized  images,  taking 
advantage  of  the  raster  display's  ability  to  draw  (possibly 
colored)  solid  areas. 

In  a 2D  package  developed  by  Sproull  and  Newman  (Sproul/ 
Newman  75) , a polygonal  area  is  specified  by  calling  the 
procedure  FILLBEGIN,  followed  by  a sequence  of  LINE  or  LINETO 
procedure  invocations  to  define  the  polygon,  followed  finally 
by  FILLEND  to  mark  the  end  of  the  polygon.  Polygons  and  other 
output  primitives  are  contained  in  segments,  whose  numeric 
name  is  used  to  determine  the  priority  of  overlapping 

primitives.  Within  a segment,  temporal  sequence  determines 
visibility. 

Fulton  and  Duquet  added  a few  area-oriented  output  primitives 
(circles,  triangles,  rectangles)  to  BASIC  for  use  with  a plasma 
panel  (Fulton/Duquet  75) . Each  primitive  can  be  erased,  by 
respecifying  the  parameters  used  to  generate  it.  This  allows 
the  appropriate  cells  of  the  plasma  panel  to  be  turned  off.  If 
several  primitives  overlap,  temporal  sequence  determines  which 
cells  are  turned  off  by  an  erasure. 

The  2d  Interactive  Graphics  Programming  Language  (GPL)  was 
first  developed  by  O'Brien  and  Bown  (0 'Brien/Bown  75).  It  is 
now  provided  by  Norpack  (a  raster  system  manufacturer) , with 
raster  extensions,  under  the  IGPL  name  IGPL77  . The  system 
currently  allows  shaded  rectangles  to  be  drawn,  and  is  being 
extended  to  include  convex  and  concave  polygons.  The  system 


provides  a segment-like  facility,  to  group  output  primitives. 
Temporal  sequence  of  creation  determines  visibility  of 
overlapping  primitives. 


j 

I 

GPAC,  a 2d  system  developed  at  Toronto  by  Reeves  (Reeves  77) , 
used  the  FILLBEGIN. . .FILLEND  construct  to  define  polygonal 
areas.  Segments  have  a depth  attribute  which  is  used  when 

1 

t output  primitives  from  different  segments  overlap.  Within  a 

segment,  temporal  order  of  creation  governs,  with  the  most 
recently  created  primitive  dominating  others. 

, The  group  at  MIT  has  developed  several  low-level  access 

packages  (AMG75,  AMG76,  AMG77) , which  provide  an  output-oriented 
capability,  without  provision  for  segmentation.  The  refresh 
buffer  can  be  manipulated  by  translating,  scaling,  and  rotating 
rectangular  regions.  Output  primitives  (lines,  circles,  text, 
polygons)  can  be  placed  into  the  buffer. 
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The  most  fundamental  design  objective  of  this  work  is 
to  extend  the  Core  System  for  raster  graphics  in  a fashion 
compatible  with  the  design  objectives  of  the  Core  System  itself, 
j so  that  the  extended  system  might  possess  a conceptual  integrity 

in  its  own  right.  These  objectives,  summarized  in  (van  Dam/ 
Newman  78)  and  detailed  in  (GSPC) , demand  that  simplicity, 
minimality  of  function  (but  without  substantial  loss  of 
capability) , and  consistency  be  sought. 

Raster  graphics  implies  the  need  for  color  and  intensity 
specifications,  solid  shaded  areas  (which  can  in  turn  hide 
or  obscure  other  areas) , and  the  display  of  images  created  by 
cameras,  X-rays,  radars,  ultrasound,  CAT,  etc.  While  the 
extensions  are  thus  designed  to  allow  display  of  solid  areas 
of  given  color  or  intensity,  the  extensions  do  not  include 
the  lighting  models  which  would  allow  surface  shading  to  be 
calculated  by  the  extended  core.  Lighting  models  (as  well  as 
surface  texturing  models)  are  considered  as  higher-level  appli- 
cation-oriented capabilities,  which  can  be  created  using  the 
capabilities  of  the  extended  Core  Graphics  System.  Furthermore, 
these  are  still  active  research  areas  in  their  own  right. 

The  prototypical  raster  graphics  system  for  which  the 
extensions  are  designed  is  shown  in  Figure  1. 

The  image  creation  system  is  often  able  to  process 
lines,  text,  points,  and  areas  specified  in  2D.  Its  output 
is  placed  in  the  refresh  buffer  as  the  pixel  values  needed  to 
cause  the  appropriate  entities  to  be  displayed.  The  size  of 
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the  refresh  buffer  and  number  of  bits/pixel  are  variable. 

The  image  display  system  reads  the  refresh  buffer  in  synchronism 
with  a TV  raster  scan,  using  the  pixel  values  to  control  the 
color  or  intensity  of  points  on  the  display  screen.  An 
optional  look-up  table  in  this  system  can  dynamically  assign 
intensities  or  colors  to  pixel  values.  There  is  a fixed  1-1 
correspondence  between  pixels  in  the  refresh  buffer  and  points 
on  the  display  screen  (some  contemporary  raster  systems  do 
not  impose  this  restriction) . The  interaction  system  allows 
devices  such  as  keyboards  and  tablets  to  be  used,  with  appro- 
priate feedback  displayed  on  the  screen. 

The  look-up  table  is  treated  as  an  option,  because  it  is 
not  a standard  raster  display  system  capability.  On  the  other 
hand,  it  is  quite  useful  for  image  analysis  and  interactive, 
graphics.  Thus  another  design  objective  is  to  incorporate  the 
look-up  table  into  the  extensions,  but  making  it  transparent  to 
applications  which  don't  use  it. 


. The  Core  Graphics  System 


A very  brief  review  of  the  current  capabilities  of  the 
Core  System  is  appropriate,  as  it  sets  the  stage  for  the 
following  discussion  of  extensions  to  the  Core  System. 

4.1  Graphics  Output  Primitives 

Objects  in  2D  and  3D  world  (application)  Coordinates  are 
described  to  the  Core  System  as  combinations  of  moves,  lines, 
line  sequences  (called  polylines) , markers  (a  generalization 
of  points) , and  text.  A current  position  is  used  as  the 
starting  point  for  lines  and  text  strings.  The  output  primi- 
tives' positions  can  be  specified  as  absolute  coordinates,  or 
relative  to  the  current  position. 

4.2  Output  Primitive  Attributes 

The  current  value  of  these  attributes  determine  the  detailed 
appearance  of  output  primitives  when  they  are  created.  Once  an 
output  primitive  is  created,  its  attribute  values  can  be  changed 
only  by  deleting  the  primitive  (using  segments,  described 
below) , and  then  respecifying  the  primitive  to  the  Core  System 
after  first  establishing  new  attribute  values.  Primitive  attributes 
are:  linestyle  (dot,  dash,  solid,  etc.),  linewidth,  intensity, 

color,  character  font,  character  size,  character  spacing,  character 
orientation,  and  character  quality. 

4.3  Grouping,  Naming,  and  Modification 

Each  output  primitive  is  placed  into  one  and  only  one 


which  are  named,  are  the  unit  of  picture  modifications  for 
interaction.  Segments  can  be  deleted,  renamed,  and  have  their 
attributes  modified.  In  addition  to  the  grouping  provided  by 
segments,  an  output  primitive  within  a named  segment  may  be 
placed  in  a named  group.  Segments  cannot  contain  references 
to  other  segments;  thus  picture  hierarchies  and  copies  of 
segments  cannot  be  created.  The  segment  and  group  names  are 
used  for  pick  (l.'ght  pen)  identification.  When  a segment  is 
created,  the  current  position  is  set  to  the  origin,  and  all 
output  primitive  attributes  are  reset  to  their  defaults. 

4.4  Segment  Attributes 

Segments  have  dynamic  attributes,  which  can  be  changed 
either  while  a segment  is  being  constructed  or  at  a later 
time.  These  attributes  are  visibility  (whether  the  segment 
is  actually  displayed) , detectability  (whether  the  segment 
can  be  "seen"  by  a light  pen  or  other  pick  device) , highlight 
(calling  the  operator's  attention  to  the  segment  by  blinking 
or  intensifying  it) , and  an  image  transformation  (applied, 
after  the  viewing  transformation  has  been  performed,  to  those 
output  primitives  surviving  the  clipping  process) . 

4.5  Viewing  Transformations 

Viewing  of  2D  objects  is  specified  with  the  traditional 
window  and  viewport  except  that  the  window  may  be  inclined  with 
respect  to  the  principal  axes.  The  object  can  be  clipped 
against  the  window.  In  3D,  a viewer  is  imagined  to  be  at 
an  arbitrary  point  in  three-space,  looking  toward  some  other 
point.  The  field  of  view  is  determined  by  specifying  a rectangle 
in  a projection  plane,  with  the  rectangle  then  mapped  into  the 
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viewport.  If  the  viewport  is  infinitely  far  away,  an  ortho- 
graphic projection  results;  otherwise,  a perspective  projection 
results.  The  3D  object  can  be  clipped  against  a 3D  solid  volume: 
a pyramid  for  perspective  projections,  and  a solid  rectangle 
for  parallel  projections.  The  image  of  a viewed  object, 
be  it  2d  or  3D,  can  be  translated,  scaled,  and  rotated  after 
the  image  has  been  created.  2d  viewing  is  a proper  subset  of 
3D  viewing,  with  all  ?D  objects  in  the  Z = 0 plane. 

4 . 6 Interaction 

Five  classes  of  devices  for  operator  input  are  supported. 
Picks  provide  the  segment  and  group  names  of  output  primitives. 
Locators  provide  a position,  while  valuators  provide  a scalar 
value.  Text  input  devices  provide  character  strings,  and 
choice  devices  provide  a selection  from  several  alternatives. 

The  common  physical  prototypes  for  picks  are  light  pens;  for 
locators,  joysticks  and  tablets;  for  valuator,  dials;  for 
text,  alphanumeric  keyboards;  and  for  choice,  programmed 
function  keyboards.  Each  device  class  has  a system-defined 
feedback,  which  can  be  turned  on  or  off.  Picks,  text,  and 
choice,  when  enabled,  can  place  event  reports  on  an  input 
queue,  which  can  be  interrogated  by  the  application  program. 
Locators  and  valuators,  when  enabled,  can  be  sampled  by  the 
application  program,  and  can  also  have  their  input  information 
placed  on  the  input  queue  in  conjunction  with  the  occurrence 
of  an  event. 
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5.  The  Raster  Graphics  Extensions 

In  this  section  the  raster  graphics  extensions  to  the 
Core  System  are  described.  The  extensions  naturally  fall  into 
several  areas,  each  of  which  is  treated  in  a separate  subsection. 
There  is  usually  a discussion  of  design  alternatives,  followed 
by  a more  detailed  discussion  of  the  selected  alternatives. 

A reference  manual  defining  the  details  of  each  subroutine 
added  to  the  Core  System  is  an  appendix  to  this  paper. 

5.1  Hidden  Surface  Removal 

The  Core  System  currently  has  no  capabilities  for  defining 
surfaces,  so  the  hidden  surface  and  hidden  edge  removal  have 
never  been  considered.  However,  this  capability  is  central  to 
effectively  using  raster  graphics.  The  key  question  here  is 
how  the  application  programmer  tells  the  graphics  package 
which  surfaces  obscure  other  surfaces.  There  are  several 
possible  solutions. 

For  strictly  2D  systems,  temporal  priority  can  be  used: 
the  most  recently  displayed  segment  or  output  primitive  has 
priority  over  other  segments  and  output  primitives.  This 
is  particularly  easy  to  implement.  Alternatively,  segments 
(or  perhaps  output  primitives)  can  explicitly  be  assigned 
priorities,  while  within  a segment,  terporal  sequence  is  used.  Impleinan- 
tation  of  this  latter  case  is  more  difficult  than  the  former. 

The  assigned  priorities  can  be  either  static  (permanently 
fixed  when  the  segment  is  created)  or  dynamic  (changeable  after 
the  segment  is  created).  In  either  case,  this  approach  is 
sometimes  called  a 2J$D  system.  The  priorities  are  akin  to 
the  depths  of  segments  along  a z-axis,  and  each  segment  lies 
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in  a plane  normal  to  the  Z-axis.  The  segment  with  priority  1 
(the  highest  priority)  is  in  the  Z=0  plane.  The  collection  of 
segments  is  viewed  from  infinity  on  the  negative  Z-axis. 
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For  3D,  the  basic  answer  is  that  the  X,Y,Z  coordinates 
of  the  surfaces  plus  the  viewing  specification  (where  the 
viewer  is  located)  provide  all  the  information  needed  by 
hidden  surface  algorithms.  However,  there  is  more  to  the 
problem.  In  the  Core  System,  many  segments  can  simultaneously 
be  displayed  on  the  view  surface,  and  each  segment  can  have  a 
different  viewing  specification.  Hence  the  above  "basic" 
answer  is  true  only  for  individual  segments. 

The  synthetic  camera  analogy  for  the  Core  System  is  useful 
in  motivating  the  difficulty.  Each  segment  and  its  viewing 
specification  defines  a "photograph",  which  is  displayed  within 
a viewport  on  the  view  surface . When  several  viewports 
overlap  or  are  in  fact  identical  (frequently  the  case) , the 
photographs  overlap.  For  line-drawings,  this  is  no  problem, 
since  each  photograph  is  just  a collection  of  lines.  Thus 
one  photograph  does  not  obscure  another  photograph. 

For  raster  graphics,  a photograph  can  include  solid 
areas,  which  can  obscure  lines  and  other  solid  areas.  One  might 
attempt  to  resolve  this  by  assigning  priorities  to  each  photo- 
graph (i.e.,  segment).  But  what  of  a view  of  a single  object 
composed  of  multiple  segments?  The  determination  of  the 
visibility  of  surfaces  in  each  segment  must  be  done  in  three 
dimensions,  before  the  photograph  is  actually  created,  con- 
sidering all  the  segments  defining  the  object.  One  way  to 
permit  this  is  to  define  a second  level  of  structuring  in  the 
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Core  System  - a collection  of  segments.  Hidden  surface  removal 
in  3D  would  be  done  on  each  such  collection  of  segments.  This 
approach  is  unacceptable,  because  it  would  introduce  a second 
level  of  structuring  to  the  Core  System.  Furthermore,  the 
priority  of  the  photographs  produced  by  each  such  collection 
of  segments  must  still  be  resolved. 

There  is  another,  more  attractive  way  to  deal  with  hidden 
surface  removal.  In  level  4 of  the  Core  System,  the  viewing 
transformation  specifies  not  a projection  from  3D  world  coor- 
dinates into  a rectangular  2D  normalized  device  coordinate 
viewport  on  the  view  surface,  but  rather  a transformation 
from  3D  world  coordinates  into  a 3D  solid  rectangular  viewport 
in  3D  normalized  device  coordinates.  The  display  on  the  view 
surface  is  then  a parallel  projection  of  the  entire  contents 
of  3D  NDC  space  (the  unit  cube)  onto  the  front  plane  of  the 
unit  cube.  Figure  2 illustrates  this.  Two  segments  with 
identical  3D  viewports  then  have  their  output  primitives  in 
the  same  part  of  3D  NDC  space.  The  hidden  surface  algorithm 
operates  on  all  of  3D  NDC  space,  producing  a single  unified 
image  or  photograph  on  the  view  surface.  Thus  there  is  no  need 
to  be  concerned  about  the  priority  of  several  overlapping 
photographs  on  the  view  surface.  If  two  output  primitives  have 
identical  coordinates  in  3D  NDC  space,  then  temporal  priority 
can  still  be  used  to  determine  visibility.  The  most  recently 
created  output  primitive  would  take  priority  over  others. 

The  transformation  of  a 3D  view  volume  (be  it  the  truncated 
pyramid  of  a perspective  view  or  the  solid  rectangle  of  a 
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parallel  view)  into  a 3D  unit  cube  is  straightforward  (Sutherland/ 
Hodgman  74,  Sutherland/Sproull/Schumacker  74) , and  is  commonly 
used  preparatory  to  use  of  a hidden  surface  algorithm.  This 
concept  is  being  extended  here  to  multiple  3D  viewports 
within  a unit  cube.  In  some  cases,  such  as  displaying  an 
airport  runway  and  surrounding  buildings,  a single  viewport 
would  be  used,  with  size  equal  to  the  unit  cube.  In  other 
cases,  such  as  simultaneously  displaying  front,  top,  side,  and 
isometric  projections  of  the  same  object,  several  non-overlapping 
(as  seen  from  the  viewsurface)  viewports  would  be  used.  In 
still  other  cases,  such  as  displaying  an  object  with  a super- 
imposed cut-out  showing  enlarged  detail  of  a particular  area, 
overlapping  (as  seen  from  the  view  surface)  viewports  would 
be  used.  Figures  3 and  4 show  these  two  latter  cases. 

If  clipping  is  enabled  while  the  output  primitives  are 
defined  to  the  Core  System,  then  in  3D  NDC  space  all  output 
primitives  will  be  contained  within  3D  viewports.  Hidden  surface 
algorithms  can  use  this  knowledge  to  advantage,  to  avoid 
unnecessary  comparisons  between  output  primitives. 

Several  attractive  special  cases  arise  within  this 
general  conceptual  model.  Consider  first  the  2d  temporal 
priority  discussed  earlier.  For  many  simple  2D  applications 
of  raster  graphics  such  as  displaying  charts  and  graphs, 

2d  temporal  priority  is  an  attractive  and  useful  concept  for 
a programmer  to  use.  This  concept  is  in  fact  the  default  for 
the  Core  System,  because  all  2D  viewports  (which  is  the 
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FIGURE  3 

ARRANGEMENT  OF  TWO  3D  VIEWPORTS  SO  THAT  RESULTING 
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FIGURE  4 

ARRANGEMENT  OF  FOUR  3D  VIEWPORTS  SO  THAT 
THE  RESULTING  DISPLAY  HAS  FOUR  SEPARATE 
VIEWS  ON  VIEW  SURFACE 
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typically-used  default)  lie  in  the  front  face  of  3D  NDC  space 
(the  Z=0  plane) . Hence  output  primitives  in  NDC  space  have  no 
depth,  so  the  hidden  surface  algorithms  have  no  basis  for 
deciding  which  output  primitives  are  visible.  It  is  in  just 
this  case  that  temporal  priority  is  used. 

As  a second  case,  consider  the  2*sD  case,  wherein  each 
segment  has  an  explicit  priority  for  visibility.  All  output 
primitives,  however  are  2D. 

The  effect  of  2*sD  can  be 

achieved  by  using  segment  priorities  in  the  range  0-1.  A 

segment  with  priority  P and  2D  viewport  defined  by  corner 

points  (X  . ,Y  . ) , (X  , Y ) would  in  fact  have  a 3D 
c ram  mm  max  max 

viewport  defined  by  corner  points  <Xmin ^min,P) , <xmax'Ymax, P) • 
That  is,  the  3D  viewport  is  in  the  Z=P  plane.  Hence  the  effect 
of  the  depth  priority  for  a 2D  segment  is  achieved  by  putting 
the  image  of  the  segment  on  the  appropriate  constant  Z plane 
in  3D  NDC  space  , as  in  Figure  5. 

If  the  depth  priorities  are  dynamic,  changing  a priority 
can  be  effected  by  applying  an  image  transformation  to  the 
segment:  a translation  along  the  Z-axis  of  NDC  space  would 

be  used  to  reposition  the  image  in  the  appropriate  plane  of 
constant  Z. 

Thus  the  facilities  for  either  a static  or  dynamic  2%  D 
priority  capability  are  available.  A novice  programmer  might 
have  trouble  using  the  facilities  in  the  context  of  3D 
viewports  and  NDC  space,  but  a very  simple  set  of  additional 
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FIGURE  5 

USE  OF  VIEWPORTS  ON  PARALLEL  PLANES  IN  3D  NDC  SPACE 
TO  IMPLEMENT  EXPLICIT  (2>3D)  DEPTH  PRIORITY 
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subroutines  could  be  built  on  top  of  the  extended  Core  System 
to  make  the  facilities  available  in  a more  tractable  form. 


It  so  happens,  then,  that  the  Core  System  already 
contains  the  key  concept  needed  to  provide  hidden  surface 
removal  in  a general  and  flexible  way  - 3D  viewports  and  3D 
NDC  space.  Furthermore,  the  concept  can  be  used  to  provide 
two  other  hidden  surface  concepts  commonly  used  in  2d  - temporal 
priority  and  2^D  priority. 

5.2  Polygons 

The  basis  for  s.  ded  (or  colored)  areas  and  hidden  surface 
removal  is  the  specification  of  bounded  surfaces,  which  then 
can  obscure  either  other  bounded  surfaces  or  the  other  primitives: 
lines,  markers,  and  text.  The  Core  System  extensions  deal 
only  with  planar  bounded  surfaces  which  can  be  defined  by  poly- 
gons. Bounded  surfaces  defined  by  conic  sections,  etc.  are 
not  treated,  nor  are  non-planar  surfaces. 

Polygons  can  be  specified  in  several  ways.  Several  simple 
raster  packages  use  a sequence  such  as: 

BEGIN_FILL 

MOVE 

LINE 

LINE 

LINE 

LINE 

ENDJFILL 

The  bracketed  MOVE  and  LINE  calls  define  a sequence  of  lines, 
which  is  automatically  closed  by  the  END_FILL,  forming  a polygon. 
Several  packages  use  this  approach,  which  does,  however,  have 
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the  disadvantage  of  using  the  same  output  primitives  for  two 
purposes:  drawing  lines,  and  defining  polygons.  This  can 

hinder  program  debugging,  because  the  meaning  of  an  isolated 
call  to  LINE  depends  on  whether  a BEGIN_FILL  is  currently 
active.  Furthermore,  many  subroutine  calls  are  needed  to 
define  a polygon. 

This  first  objection  can  be  removed  by  introducing  an 
EDGE  output  primitive,  to  be  used  in  place  of  LINE  within  the 
BEGIN_FILL. . .END_FILL  pairs: 

BEGIN_FILL 

EDGE (X, Y) 

EDGE  (X,Y) 

END_FILL. 

The  second  objection  remains,  however,  and  can  be  removed  by 
using  a single  polygon  subroutine.  This  has  been  done  in  the 
extensions,  with  the  four  procedures: 

P0LYG0N_ABS_2 ( X_ARRAY , Y_ARRAY , N ) 

P0LYG0N_REL_2 ( X_ARRAY , Y_ARRAY ,N) 

POLYGON_ABS  _3 ( X_ARRAY , Y_ARRAY , Z_ARRAY , N ) 

POLYGON_REL'_3  ( X_ARRAY , Y_ARRAY  , Z_ARRAY , N ) 

Many  objects  displayed  graphically  consist  of  numerous 
interconnected  polygonal  faces.  If  each  face  were  specified 
by  a separate  polygon  primitive,  coordinates  of  shared 
vertexes  would  be  passed  to  the  Core  System  several  times, 
and  connectivity/shared  edge  information  would  have  to  be 
deduced  from  the  equality  of  vertex  coordinates.  To  avoid 
these  problems,  a second  way  of  defining  polygons  is  provided: 
the  polygon  mesh.  Polygons  in  a polygon  mesh  are  defined  in 
a 2-step  process: 


▲ 
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- A list  of  vertices,  numbered  from  1 to  N,  is  specified. 

- Each  polygon  is  defined  by  giving  a list  of  vertex 
numbers.  The  vertices  are  connected  in  the  order 
given,  with  the  last  vertex  being  connected  to  the 
first  for  closure. 

The  vertex  list  is  specified  with 

SET_P0LYG0N_MESH_ABS_2 ( X_ARRAY , Y_ARRAY ,N) 

" REL_2  (X_ARRAY,Y_ARRAY,N) 

" ABS  REL_3  (X_ARRAY,Y_ARRAY,2_ARRAY,N) 

" REL_3 

A polygon  in  the  mesh  is  specified  with 

P0LYG0N_EDGE_MESH_ABS_2  ( VERTEX_LIST,N)  • .. 

A polygon  mesh  exists  entirely  within  a segment,  and  is 
terminated  either  by  another  SET_POLYGON_MESH  or  by  closing 
the  segment. 

Polygon  meshes  have  several  attributes.  A polygon  may 
be  used  to  define  a polyhedron.  If  so,  the  polyhedron  attribute 
is  so  set.  This  allows  the  hidden-surface  algorithm  to  remove 
back-facing  polygons.  The  default  attribute  value  is  for  the 
general  case,  which  is  non-polyhedral . 

If  a polygon  mesh  does  define  a polyhedron,  it  may  be 
convex  or  non-convex.  Again,  hidden-surface  algorithms  can 
take  advantage  of  this  knowledge.  The  default  is  the  general 
case,  non-convex.  The  shading  of  polygons  can  be  controlled 
in  one  of  three  ways:  by  the  color  or  intensity  attribute  dis- 
cussed in  section  5.3,  or  by  the  pixel  array  attribute  discussed 
in  section  5.4,  or  hy  interpolated  shading.  The  polygon  type  attribute 
is  used  to  control  which  of  these  three  types  of  shading  is  used.  The 
attribute  is  set  by  the  procedure 

SET  CURRENT  POLYGON  TYPE (TYPE). 
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If  the  type  is  color/intensity  (as  opposed  to  pixel  array) , 
then  the  polygons  in  a mesh  can  each  have  different  colors 
and  intensities.  Normally,  as  a default,  each  visible  polygon 
is  displayed  with  the  specified  value.  The  interpolation  value 
can  be  used  to  request  Gouraud  (continuous)  shading  to  be 
applied  to  all  polygons  in  a mesh. 

5.3  Color  and  Intensity 

In  raster  graphics,  precise  control  of  color  and  intensity 
are  central  to  many  applications.  The  Core  System  has  a color 
attribute  and  an  intensity  attribute.  However,  there  is  no  way 
to  precisely  determine  or  specify  colors  and  intensities. 
Futhermore,  intensity  is  in  fact  one  part  of  color  specification 
so  there  is  a distinct  non-orthogonality  between  the  color 
and  intensity  attributes.  That  is,  a large  range  of  colors, 
including  all  grey  levels,  can  be  specified  using  additive 
red,  green,  and  blue  primaries,  or  using  hue,  saturation, 
and  intensity.  Given  a color  attribute,  intensity  is  redundant. 
In  the  extensions,  a view  surface  is  initialized  for  either 
color  or  intensity  use:  the  attributes  cannot  be  mixed. 
Intensity  is  retained  only  as  a convenience  for  grey-level 
applications,  and  to  maintain  upward-compatibility. 

Because  the  specific  ranges  of  colors  and  intensities 
can  vary  greatly  from  one  raster  display  to  another  and  are 
so  important  to  many  applications,  only  one  view  surface 
may  be  selected  at  a time.  This  removes  from  the  Core  System 
the  impossible  task  of  trying  to  second-guess  the  programmer 
in  mapping  a color  attribute  value  to  two  dissimilar  raster 
displays . 
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The  discussion  here  centers  on  the  color  attribute  and 
functions  for  its  control.  A parallel  set  of  capabilities  for 
the  intensity  attribute  also  exists,  and  is  described  in  the 
appended  Reference  Manual.  Conceptually,  the  extensions  define 
an  ordered  set  of  colors  specified  by  (R,G,B)  triples: 

{ (Ri,Gi ,Bi) > • This  set  is  called  the  active  color  set.  The 
size  of  the  set  varies  among  view  surfaces,  and  can  be 
determined  with  the  inquiry  function  INQUIRE_NUMBER_COLOR (M) . 
Another  inquiry  function,  INQUIRE_COLOR(I,R,G,B) , can  be 
used  to  find  the  values  of  the  R,G,  and  B components  in  the 
1 th  triple. 

The  color  attribute  for  output  primitives  is  specified  in 
one  of  two  ways:  by  value,  and  by  index.  The  function 
SET_CURRENT_COLOR(R,G,B)  specifies  the  current  value  of  the 
color  attribute.  If  the  exact  (R  G,B)  triple  specified  is  not 
included  in  the  active  color  set,  then  a best  fit  to  an 
available  triple  is  performed.  Alternatively,  the  function 
SET_CURRENT_COLOR_INDEXU)  specifies  that  the  Ith  triple 
from  the  ordered  set  is  to  be  used  as  the  color  attribute. 

This  concept  can  be  extended,  as  an  option,  for  use  with 
color  look-up  tables.  With  a look-up-table , the  previously- 
described  active  color  set  is  a subset  of  the  global  color 
set . The  size  of  the  active  color  set  is  just  the  number  of 
entries  in  the  look-un  table.  The  size  of  the  global  color 
set  is  the  size  of  the  universe  of  colors  which  can  be  placed 
in  the  look-up  table,  and  is  usually  two  raised  to  the  number 
of  bits  per  entry  in  the  table.  INQUIRE_NUMBER_GLOBAL_COLORS (N) 
can  be  used  to  find  the  size  of  the  global  color  set.  The 
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(R,G,B)  triple  for  global  color  J is  found  with  INQUIRE_GLOBAL_ 
COLOR (J,R,G,B) . An  active  color  (an  entry  in  the  look-up 
table)  can  be  changed  in  two  ways:  by  value  and  by  index, 
similarly  to  setting  the  value  of  the  color  attribute. 
REDEFINE_COLORINDEX ( J, R,G,B)  changes  the  J*"*1  active  color  to 
(R, G,B) . If  (R,G,B)  is  not  in  the  set  of  global  colors,  a 
best-fit  is  performed.  Alternatively,  an  "associative"  change 
can  be  specified  with  REDEFINE_COLOR(Rl,Gl,Bl,R2,G2,B2) . The 
active  color  (Rl,Gl,Bl)  is  changed  to  (R2,G2,B2).  If  needed, 
best  fits  are  performed  on  both  colors.  The  current  color 
attribute  must  of  course  belong  to  the  set  of  active  colors. 

If  the  current  color  attribute  has  index  I in  the  active 
color  set  and  the  meaning  of  index  I is  changed  to  some  new 
color  from  the  global  color  set,  then  the  current  color 
attribute  is  also  changed. 

This  conceptual  model  for  working  with  the  color  attribute 
is  usable  with  a wide  range  of  systems,  from  the 

inexpensive  two  to  eight  color  systems  (one  to  three  bits 
per  pixel)  without  look-up  table,  through  the  typical  eight 
bit  per  pixel  system  with  a 256  entry  look-up  table  of  twelve 
bits  per  pixel,  up  to  the  24  to  36  bit  per  pixel  systems. 

The  extended  Core  System  need  not  always  explicitly 
store  either  the  active  or  global  color  set,  but  need  only 
be  able  to  generate  triples  in  the  set.  For  instance,  the 
device  driver  for  a 24  bit  per  pixel  system  could  use  the 
24  bit  color  index  as  the  color  specification,  by  simply 
dividing  the  24  bits  into  three  groups  of  eight  bits  each.  On 
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the  other  hand,  the  device  driver  for  an  eight  color  system 


can  trivially  store  an  eight-entry  table. 

The  look-up  table  is  typically  used  to  partition  planes 
of  the  refresh  buffer  into  subsets,  to  store  several  pictures. 

The  concepts  described  here  permit  such  manipulations. 

5.4  Pixel  Arrays 

Pixel  Arrays  are  two-dimensional  arrays  of  intensity  or 
color  values.  They  occur  in  several  environments.  In  tradi- 
tional image  processing,  the  pixel  arrays  represent  real  objects, 
and  come  from  devices  such  as  cameras,  X-rays,  ultrasound 
scanners,  and  CT  systems.  In  some  cases  these  devices  produce 
direct  digital  information,  and  in  other  cases  film  must  be 
scanned  and  digitized. 

Pixel  arrays  representing  synthetic  or  modelled  objects 
are  regularly  created  by  computer  programs,  sometimes  using  quite 
sophisticated  modelling,  lighting,  and  surface  texturing. 

Artists  often  use  interactive  painting  programs  to  create 
aesthetically  pleasing  scenes  defined  by  pixel  arrays.  Part  of 
the  objective  of  extending  the  Core  System  for  raster  graphics 
is  to  allow  such  pixel  arrays  to  be  displayed  easily,  along 
with  lines  and  shaded  polygons.  Pixel  arrays  could  easily  be 
treated  as  a rather  special  type  of  output  primitive,  being 
placed  directly  onto  the  front  plane  of  3D  NDC  space.  Then, 
however,  other  constructs  in  3D  NDC  space  might  be  obscured. 
Furthermore,  using  NDC  space  is  unattractive,  because  then  the 
mixing  of  pixel  arrays  and  other  output  primitives  is  greatly 
complicated  due  to  the  use  of  two  different  coordinate  systems. 
Yet  applications  such  as  interactive  image  analysis  and 
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interpretation,  as  well  as  interactive  graphics  arts  appli- 
cations, demand  such  mixing. 

An  attractive  alternative,  used  in  the  extensions,  is 
to  place  the  pixel  arrays  into  world  coordinates,  again  as  a 
special  type  of  output  primitive.  Where  would  the  pixel 
array  be  placed?  Presumably  on  some  plane,  oriented  arbitrarily 
in  3D  world  coordinates. 

One  might  wish  to  display  not  the  entire  rectangular 
pixel  array,  but  rather  some  portion  thereof:  this  would  occur 
if  a photo  were  cropped  around  an  irregular  contour.  Indicating 
the  portion  of  the  pixel  array  to  be  ignored  can  be  done  in 
several  ways.  A special  pixel  value  meaning  "ignore  me" 
might  be  used,  or  as  is  done  in  the  extensions,  a polygon  can 
be  used  to  circumscribe  that  part  of  the  pixel  array  to  be 
displayed. 

How  can  the  plane  on  which  the  pixel  array  will  be  dis- 
played and  the  polygon  circumscribing  some  or  all  of  the 
pixel  array  be  best  specified?  A special  construct  for  this 
would  work,  but  is  quite  unnecessary,  because  the  extensions 
already  include  polygons,  as  described  in  an  earlier  section. 

All  that  is  needed  is  some  mechanism  for  mapping  a pixel  array 
onto  a polygon,  and  for  indicating  that  a polygon  is  to  be 
shaded  not  with  the  current  color  intensity  attribute,  but 
rather  with  a pixel  array.  This  latter  matter  is  handled 
by  the  POLYGON_TYPE  attribute,  which  has  three  values:  plain, 
interpolated,  and  painted.  A plain  polygon  is  displayed  using 
the  current  color  or  intensity,  while  a painted  polygon  is 
displayed  using  the  current  pixel  array  and  pixel  array  to 
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polygon  mapping.  The  default  polygon  type  is  plain.  An 
interpolated  polygon  is  shaded  by  linear  interpolation  of  vertex 
colors  or  intensities  so  that  Gourand  shading  is  possible  as 
a special  case. 

If  a polygon  is  to  be  painted,  a mapping  is  needed  as 
shown  in  Figure  6 . A polygonal  part  of  the  pixel  array  is 
mapped  into  a similar  polygonal  part  of  the  3D  world.  Appro- 
priate averaging  or  convolutions  are  used  to  find  the  correct 
pixel  values  for  that  part  of  the  view  surface  surrounded  by 
a visible  painted  polygon. 

The  mapping  from  a pixel  array  to  a 3D  world  coordinate 
polygon  is  specified  in  several  steps.  The  pixel  array,  for 
convenience,  can  be  thought  of  as  having  an  arbitrary  size, 
defined  by  SET_PIXEL_ARRAY_EXTENT . The  two  parameters  are 
the  width  and  height  of  the  pixel  array,  in  arbitrary  units 
(some  applications  may  conveniently  think  of  these  as  world 
coordinate  units) . Figure  6 shows  the  pixel  array  and  its 
length  and  height.  The  (0,0)  origin  is  always  at  the  lower 
left  of  the  pixel  array,  in  the  center  of  the  pixel.  Similarly 
the  point  ( X_LENGTH , Y_LENGTH)  is  in  the  center  of  the  upper 
right  pixel.  Using  this  pixel  array  coordinate  system,  three 
points  in  the  pixel  array  (not  necessarily  centers  of  pixels) 
are  defined  and  associated  with  three  vertices  of  the  world 
coordinate  polygon.  The  three  points  in  the  pixel  array  and 
three  points  on  the  world  coordinate  polygon  define  a mapping 
which  transforms  the  pixel  array  coordinate  space  onto  the 
plane  of  the  three  polygon  points.  Whatever  part  of  the  pixel 
array  falls  within  the  polygon  is  visible,  as  in  Figure  6 . 


43 


IN  3D  WORLD 
COORDINATES 


FIGURE  6 

TRANSFORMATION  OF  PIXEL  ARRAY  INTO  WORLD 
COORDINATES.  ONLY  PORTION  OF  ARRAY  WITHIN 
POLYGON  IS  DISPLAYED. 
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(Naturally  the  three  points  cannot  be  colinear) . This  mapping 
is  defined  with  the  function  SET  VERTEX  MAP. 


This  approach  is  rather  powerful.  It  can  be  used  for 
texture  mapping,  placing  pictures  on  walls  of  rooms  being 
modelled  and  displayed,  but  it  can  also  easily  be  used  to 
j display  rectangular  images  in  a rectangular  polygon  on  the 

view  surface.  This  notion  of  mapping  images  onto  polygons 
and  thence  the  polygons  to  the  view  surface  is  at  the  heart  of 
how  the  extensions  to  the  Core  System  deal  with  images. 


5.5  Operations  on  the  View  Surface 


For  raster  graphics  systems  the  view  surface  and  refresh 
buffer  are  one  and  the  same.  The  refresh  buffer  is  made 
directly  available  to  the  application  programmer,  to  read  or 
write  individual  pixels  or  arrays  of  pixels.  Pixels  are  of 
course  addressed  using  the  intermediary  of  normalized  device 
coordinates.  This  is  perhaps  the  most  and  only  substantial 
area  in  which  the  extensions  depart  significantly  from  the 
Core  System  philosophy:  for  vector  systems,  the  Core  System 
explicitly  does  not  make  a real  or  pseudo  display  file  directly 
available  to  the  application  program  for  manipulation  and 
modification . 

This  has  been  done  for  numerous  reasons.  Some  interaction 
techniques  must  directly  modify  and  restore  portions  of  the 
refresh  buffer.  Tremendous  amounts  of  computer  time  might 
go  into  calculating  pixel  values  for  a single  picture.  That 
time  would  be  lost  if  the  view  surface  pixel  array  could  not 
be  saved.  (A  similar  cost  does  not  exist  with  line-drawing 
display  files.)  Powerful  visual  effects  can  be  achieved  by 
some  view  surface  (pixel  array)  manipulations , or  by  combining 
on  a screen  the  outputs  of  numerous  different  programs  which 
creat  images  in  different  ways. 

On  the  other  hand,  no  geometrical  transformations  on  the 
view  surface  have  been  defined.  If  the  view  surface  pixel 
array  can  be  read  and  written,  then  a multitude  of  geometrical 
(rotate,  scale,  translate,  etc.)  and  image-oriented  (average, 
filter,  etc.)  operations  can  be  implemented. 
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5.6  Control 


In  a standard  line-drawing  graphics  package,  output 
primitives  can  always  be  displayed  as  soon  as  they  are 
defined.  If  hidden  surfaces  (or  edges)  are  to  be  removed, 
however,  then  numerous  factors  suggest  that  all  output 
primitives  must  usually  be  defined  before  any 
output  primitives  can  be  displayed.  Some  control  function 
is  needed  to  indicate  when  all  output  primitives  have  been 
defined,  so  that  a hidden  surface  algorithm  can  be  initiated. 
Without  such  a function,  the  Core  System  would  be  forced  to 
display  each  visible  output  primitive  as  it  is  defined, 
possibly  also  removing  from  the  display  output  primitives 
(or  portions  thereof)  obscured  by  the  new  output  primitive. 

The  Core  System's  batch  of  updates  function  is  just 
right  for  this  purpose.  The  effect  of  the  END_BATCH_OF_UPDATES 
function  depends  on  which  one  of  three  display  modes  has  been 
set:  "fast",  "hidden  edge",  and  "hidden  surface”.  In  fast 

mode,  output  primitives  are  displayed  immediately,  so  the 
batching  has  no  effect  beyond  what  it  normally  does: 
guarantee  that  the  view  surface  is  up  to  date.  If  either  of 
the  other  modes  has  been  set,  nothing  is  displayed  until  the 
end  of  batch  occurs,  at  which  time  the  (possibly  slow)  hidden 
edge  or  surface  algorithm  is  initiated.  If  a line-drawing  view 
surface  has  been  selected,  then  "hidden  surface"  display 
mode,  "fast",  exists  to  give  the  application  program  explicit 
control  over  how  often  the  hidden  edge  or  surface  algorithm 
is  used,  and  to  give  compatibility  with  the  existing  Core 
System. 
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6 . Summary 

In  general,  the  Core  System  proved  to  be  a receptive 
host  for  the  raster  graphics  extensions.  The  3D  NDC  space 
was  useful,  and  the  Core  System's  emphasis  on  consistency 
and  minimality  challenged  us  to  examine  numerous  alternatives 
before  a final  design. 


PART  III:  DRAFT  REFERENCE  MANUAL:  RASTER  GRAPHICS 
EXTENSIONS  TO  THE  CORE  SYSTEM 


2 OUTPUT  PRIMITIVES 


2.2  FUNCTIONAL  CAPABILITIES 


2.2.6  POLYGON  PRIMITIVES 


2. 2. 6. 1 POLYGON 

POLYGGN_AES_2  ( X_AKRAY , Y_ARRRA Y , N ) 

PCLYGON_ABS  3 ( X_ARRAY  , Y_ARRAY,  Z_ARRAY , N) 

PGLYGOK_REL~2  (X_ ARRAY, Y_ARRAY ,N) 

POLYGON” REL_3  ( X_ARRAY , Y_ARRAY , Z_ARRA Y , N ) 

This  function  is  used  to  define  a polygon  with  a vertex  list 
in  world  coordinates.  The  polygon  is  the  region  enclosed  by 
the  connected  seouence  of  lines  that  starts  at  the  first 
vertex  in  the  array,  joins  all  the  other  vertices  in  order, 
then  returns  to  the  first  vertex  to  close  the  defined 
area. Because  closure  is  implied  the  CP  is  set  to  the 
coordinates  of  the  first  vertex  at  the  completion  of  the 
primitive. 

The  color  pattern  of  the  interior  of  the  polygon  will  depend 
on  the  current  polygon  type  and  the  corresponding  set  of 
primitive  attributes  (see  SET_PGLYGON_TYPE) . 

General  Errors: 

1.  There  is  no  selected  view  surface. 

2.  No  segment  is  open. 

3.  N is  <=  2. 

4.  Some  vertices  are  not  coplanar  (beyond  an  as  yet  undefined 
epsilon) . 

Errors  for  Painteo  Polygons: 

3.  There  is  no  pixel  array  format  specified. 

6.  A vertex  index  given  in  SET_PIXEL_MAP  call  is  > N. 

7.  A vertex  definea  in  pixel  map  coordinates 
falls  outside  the  pixel  map. 

8.  The  triangle  definea  on  the  pixel  map  is  not 
similar  to  the  one  defined  in  world  coordinates 
(the  length  of  all  3 sides  of  both  triangles 
must  be  proportional  to  be  similar  triangles). 

Errors  for  Shaded  Polygons: 

9.  The  number  of  vertices  specified  in  the  current 
vertex  color  list  (see  SETTINC_VEFTEX_COLOFS) 
is  not  equal  to  N. 


1 


2. 2. 6. 2 SET_POLYGON_MESH 

SET_PCLYGON  MESH_ABS_2  (X_ARRAY , Y_AFFAY , N) 
SET_P0LYG0N_MESH_AES_3  (X_ARRAY  , Y_AF.RAY  , Z_APRAY  ,N) 
SET_P0LYG0N_MESH_REL_2  ( X_ARRAY , Y_ARFA Y , N) 
SET_P0LYG0N_MEEH_REL_3  ( X_ARRAY , Y_AFFAY , Z_ARRAY ,N) 

This  function  is  used  to  begin  the  definition  of  a new 
polygon  mesh.  It  specifies  the  entire  vertex  list  for  the 
i,  esh  of  polygons  defined  in  world  coordinates.  This  list  will 
be  referenced  by  the  POLYGON  EDGE_^LIST  function.  The  CP  is 
not  use!  or  updated  by  this  function. 

The  current  polygon  iresh  shape  in  effect  (see  £ET_CURFENT 
_ FOLYGO 1 NESH_SHAFE)  when  the  SET_POLYGON_KESH  function  is 
invoked  letermines  the  type  of  the  fresh. 

A fresh  is  frade  up  of  a series  of  polygon  elements  defined 
using  tn°  POLYGCN_EDGE_LIST  command. 

A particular  mesh  is  completed  (closed)  when  another 

SET  POLYGON  MESH  function  is  invoked  or  a Segment  is  closed. 


Default  — N equals  zero. 

Errors : 

1.  There  is  no  view  surface  selected. 

2.  No  segment  is  open. 

3.  N <=  2. 


2. 2. 6. 3 IN0UIFE_POLYGON_MESH 

INQUI  FE_P0LYC0N_N'ESH_ABS_2  ( X_ARFAY , Y_AFFAY  ,N) 
INCU1FE_P0LYG0N_MESH_ABS_3  ( X_AFF  AY  , Y_AFF:A Y , Z_AFRAY , N ) 

These  functions  return  the  current  polygon  mesh  vertex  lists 
in  absolute  world  coordinates. 

Errors:  None. 
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2. 2. 6. 4 PGLYGON_EDGE_LIST  (VERTEX_INDEX_ARRAY,N) 

This  function  is  used  to  define  a single  polygon  in  a polygon 
mesh,  by  specifying  which  vertices  from  the  vertex  list  (see 
SET_FGLYGON_MESH)  are  to  be  used.  The  polygon  is  the  region 
enclosed  by  the  connected  sequence  of  lines  that  start  with 
the  first  vertex  specifieo  by  the  VERTEX_INDEX_ARRAY,  joins 
all  the  other  vertices  in  order,  then  returns  to  the  first 
vertex  to  close  the  aefined  area.  Because  closure  is  implied 
the  Cl  is  set  to  the  first  vertex  at  the  completion  of  the 
pr i mi t ive . 

The  color  pattern  of  the  interior  of  the  polygon  will  depend 
on  the  current  polygon  type  and  the  corresponding  set  of 
primitive  attributes  (see  SET_POLYGON_TYPE) . 

General  Errors: 

1.  There  is  no  selected  view  surface. 

2.  No  segment  is  open. 

3.  N is  <=  2. 

4.  Sere  vertices  are  not  coplanar  (beyond  an  as  yet  undefined 
epsi Ion)  . 

5.  A VEFTEX_ INDEX  is  out  of  range  of  the  mesh  vertex  list. 

6.  There  is  no  vertex  list  in  existence. 

Errors  for  Painted  Polygons: 

7.  There  is  no  pixel  array  format  specified. 

8.  A vertex  index  given  in  the  SET_PIXEL_MAP  call  is  > N. 

9 . A vertex  aefineo  in  pixel  map  coordinates 
falls  outside  the  pixel  map. 

10.  The  triangle  defined  on  the  pixel  map  is  not 
similar  to  the  one  defined  in  world  coordinates 
(the  length  of  all  3 sides  of  both  triangles 
must  be  proportional  to  be  similar  triangles). 

Errors  for  Shadeo  Polygons: 

11.  The  number  of  vertices  specified  in  the  current 
vertex  color  list  (see  £ETTING_VERTEX_COLCRS) 
is  not.  equal  to  N. 
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4 ATTRIBUTES 


4.2  FUNCTIONAL  CAPABILITIES 

4. 2. 1.1.1  SET_CUFFENT_POLYGON_TYPE  (TYPE) 

This  function  sets  the  current  system-maintained  attribute 
value  of  the  polygon  type  to  either  plain,  painted  or  shaded. 
A plain  polygon  is  filled  with  a single  color  specified  by 
the  current  color  (or  current  intensity)  attribute.  A painted 
polygon  is  filled  with  an  image  made  up  of  differently 
colored  pixels.  The  current  pixel  array,  set  by  other 
primitive  attribute  routines,  defines  the  pixel  values.  A 
shaded  polygon  is  filled  by  linearly  interpolating  between 
the  color  specified  at  each  vertex  (Gouraud  shading).  The 
color  (or  intensity)  value  at  each  vertex  are  set  by  other 
primitive  attribute  functions. 

Default  — Currrent  Polygon  Type  is  Plain. 

Errors: 

1.  No  segment  is  open. 

2.  Invalid  attribute  value. 


4. 2. 1.1. 2 SET_CURRENT_COLOR 
SET_CURF.ENT_COLOR  (R,G,B) 

This  is  the  currently  defined  procedure  for  setting  the  color 
attribute.  R,G,B  are  in  the  range  of  0,1. 

Errors: 

1.  No  view  surface  is  selected. 

2.  Segment  is  not  open. 

3.  Invalid  attribute  value. 

4.  Type  of  the  selected  view  surface  is  gray  level 
rather  than  color. 


SET_CURRENT_COLGF_ INDEX  (I)  1 <=  I <=  N 

The  current  color  is  set  to  the  Ith  color  of  the  currently 
selected  view  surface.  This  is  the  color  which  would  be 
returnee  by  a call  to  INCLINE  _CCLOR_VALUE  (I,P,G,B),  with 
the  sane  view  surface  selected. 

Errors: 

1.  No  view  surface  is  selected. 

2.  Segment  is  not  open. 

3.  Invalid  color  index. 

4.  Type  of  the  selected  view  surface  is 

gray  level  rather  than  color. 
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SET_CL'RFENT_INTENSITY  ( INTENSITY) 

This  is  the  currently  defined  procedure  for  setting  the 
intensity  attribute.  INTENSITY  is  in  the  range  of  0,1. 

Errors: 

1.  No  view  surface  is  selected. 

2.  Segment  is  not  open. 

3.  Invalid  attribute  value. 

4.  Type  of  the  selected  view  surface  is 
color  rather  than  gray  leve’  . 


SET_CURRENT_INTENSITY_INDEX  (I)  1 <=  I <=  N 

The  current  intensity  is  set  to  the  Ith  INTENSITY  of  the 
currently  selected  view  surface.  This  is  the  intensity  which 
would  be  returned  by  a call  to  INQUIPE_INTENSITY_VALUE  (I, 
INTENSITY)  with  the  same  view  surface  selected. 

Errors : 

1.  No  view  surface  is  selected. 

2.  Secmert  is  not  open. 

3.  Invalid  intensity  index. 

4.  Type  of  the  selected  view  surface 
is  <-olor  rather  than  gray  level. 


4. 2. 1.1. 3 SET_VET TEX_CCLORS 

SET_VERTEX_CCLORS  ( R_ARRAY , G_ARRAY,  B_AKRAY,  N) 

SET_VERTEX_ I NT ENTITIES  ( INTENSITY_ARRAY , N) 

This  function  sets  the  arrays  containing  colors  (intensities) 
of  aifleient  vertices  of  a shaded  polygon.  These  vertices 
correspord  to  the  list  of  vertices  given  either  by  a POLYGON 
or  a PCLYGON_LDGE_LIST  commands.  These  R,G,E's  (intensities) 
are  rounded  by  the  core  system  to  the  nearest  color 
(intensity)  oisplayable  on  the  selected  view  surface.  F,G,E's 
(intensities)  are  in  the  range  of  0,1. 

Defaults  — N = 0. 

Errors: 

1.  No  view  surface  is  selected. 

2.  No  segment  is  open. 

3.  N < =2  . 

4.  Invalid  attribute  value. 

5.  Type  of  selected  view  surface  is  oray  level  rather  than 
color,  or  vice  versa. 
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SET_V£RTEX_CGLCRS_BY_INDEX  ( INDEX_ARRAY , N) 
SET_VERTEX_INTENSITILS_6Y_INDEX  ( INDEX_ARRAY , N) 

This  function  sets  the  array  containing  the  indices  of  colors 
(intensities)  of  different  vertices  of  a shaded  polygon. 

These  vertices  correspond  to  the  list  of  vertices  given 
either  by  a POLYGON  or  a POLYGON_EDGE_LIST  command . 

Def aul ts  — N = 0. 

Errors : 

1.  No  view  surface  is  selected. 

2.  No  segment  is  open. 

3.  N < =2  . 

4.  Invalid  index. 

5.  Type  of  selected  view  surface  is  gray  level  rather  than 
color,  or  vice  versa. 


4. 2. 1.1.  4 SET_PIXEL_ARRAY  ( COLUMNS , ROWS , ARRAY) 

irus  lunction  is  used  to  pass  an  image's  pixel  array  and  to 
give  its  aimensions.  The  pixel  array  contains  either 
intensity  or  color  indices,  depending  on  the  type  of  view 
surface  selected  (see  SELECT_VIEX  _SURFACE) . The  method  used 
here  of  passing  an  array  is  only  feasible  for  small  image 
arrays. 

The  alternate  method  for  designating  a pixel  array  is  with 
the  S ET_PIXEL_F I LE  function.  The  most  recently  used  of  these 
two  functions  defines  the  pixel  array  to  be  used  when  a 
painted  polygon  is  specified. 

This  function  also  sets  the  defaults  for  the  pixel  array 
extent  and  the  vertex  map. 

Defaults  — A 2 by  2 array  contains  the  index  of  the 
default  intensity  or  color  attribute. 

Errors : 

1.  No  view  surface  selected. 

2.  No  segment  is  open. 

3.  COLUMNS  <=  0 or  too  large. 

4.  ROWS  <=  0 or  too  large. 


4. 2. 1.1. 5 SET_P I XEL_F I LE  ( COLUMNS , ROWS , F I LE_NAME) 

This  function  is  used  to  specify  the  name  of  a file  that 
holes  pixel  array  and  to  give  its  dimensions. 

The  alternate  method  for  designating  a pixel  array  is  with 
the  SLT_P 1 XLL_AKKA Y function.  The  most  recently  used  of  these 
two  functions  defines  the  pixel  array  to  be  used  when  a 
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painted  polygon  is  specified. 

This  function  also  sets  the  defaults  for  the  pixel  array 
extent  and  the  vertex  map,  as  described  by  SET_PIXEL- 
AFRAY_EXTENT  and  SET_VEKTEX_MAP . 

Default  — There  is  no  default  file,  only  a 
default  array  (see  SET_PIXEL_AKRAY) . 

Errors: 

1.  No  view  surface  selected. 

2.  No  segment  open. 

3.  Columns  <=  0. 

4.  Rows  <=  0. 

5.  Invalid  file  name. 


4.2.1.1.G  S£T_PIXEL_ARRAY_EXTENT  (X_LENGTH , Y_LENGTH) 

This  function  specifies  the  size,  in  world  coordinate  units 
of  the  pixel  array.  X_LEKGTH  is  the  distance  between  element 
(1,1)  and  (COLUMNS, 1)  of  the  array,  and  Y_LEN^TH  is  the 
distance  between  element:  (1,1)  and  (l,ROWS)  of  the  array.  The 
extent  defines  the  proportions  of  the  rectangular  boundary 
for  the  entire  image  and  it  gives  a convenient  coordinate 
system  for  vertex  mapping  (see  ( SET_VFPTEX_MAP) . 

The  following  defines  the  correspondence  betwern  the  pixel 
map  coordinate  system  and  the  column-row  indev  of  a pixel. 


X_MAP  = 0,0 
X_MAP  = X_LENGTH 
Y_i.AP  = 0,0 
Y NAP  = Y LENGTH 


COLUMN  = 1 

COLUMN  = MAX_C0LU’-1N 

ROW  = 1 

ROW  = MAX  ROW 


see  the  figure  on  the  next  page. 

The  pixel  extent  can  also  be  viewed  as  a way  of  changing  the 
aspect  ratio  of  the  pixel's  of  an  image.  It  thereby  allows 
the  user  to  avoid  Distortion  of  an  image  that  was  originally 
yenerated  with  non-square  pixels. 


Default  — To  facilitate  working  with  an  image  made  up  of 
square  pixels  and  to  adcress  each  pixel  directly  the  following 
aetaults  are  used: 

X_LENCTH  = COLUMNS  - 1. 

Y_ LENGTH  = ROWS  - 1. 

That  is,  each  pixel  is  assumed  to  cover  a unit  square  in 
world  coordinates. 


The  column  and  row  values  are  set  when  a pixel  array  or  file 
is  defined  or  by  the  default  pixel  array. 
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Errors : 

1.  No  view  surface  selected. 

2.  No  segment  is  open. 

3.  X_LENGTH  <=  0.0 

4.  Y LENGTH  <=  0.0 


4. 2. 1.1. 7 SET_VERTEX_MAP  ( VERTEX_INDEX_ARRAY , X_NAP_ARRAY , 

Y_MAP_ARRAY) 

This  function  specifies  the  mapping  between  the  image's  pixel 
extent  and  a polygon  specified  in  world  coordinates  (using 
the  polygon  or  polygon  mesh  functions).  This  is  accomplished 
by  defining  three  vertices  in  world  coordinates  and  three 
corresponding  points  on  the  imaoe,  in  the  coordinate  system 
defined  by  the  extent.  Once  the  mapping  is  given,  then  it  is 
possible  to  determine  the  transformation  which  makes  the 
desired  part  of  the  image  fit  (and  be  displayed)  within  the 
polygon.  The  vertices  in  world  coordinates  are  specified 
using  an  index  into  either:  the  X,Y,Z  arrays  of  a following 
polygon,  or  the  vertex  index  array  of  a POLYGON  EDGE_LIST  (in 
this  latter  case  two  levels  of  indexing  are  used  to  specify  a 
vertex).  The  three  points  on  the  image's  pixel  array  extent 
are  given  by  X and  Y coordinates  in  pixel  map  space. 
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Default  — To  facilitate  working  with  rectangular  painted 
polygons  the  following  defaults  are  given: 

VERTEX_INDEX_AFRAY  — 1,  2,  3 
X_FAp_APRAY  — 0.0,  0.0,  X_LFNGTH 

Y_P"Ap_ARRAY  — 0.0,  Y_LENGTH , Y_LENGTH 

These  defaults  always  exist,  lecause  X_LENGTH  and  Y_LE.NGTH 
always  have  either  a default  or  a user  assigned  value  (see 
£ET_pIXEL_ARp.AY_EXTENT)  . 

Errors: 

1.  No  view  surface  selected. 

2.  No  segment  open. 

3.  A VEPTEX_ INDEX  <=  0. 

4.  A X_MAP  value  is  < 0.0 

5.  AY  NAP  value  is  < 0.G 


4. 2. 1.1. 8 SET_CLRRENT_POLYGOM_NESH_£HApE  (SHApE) 

This  function  is  used  to  specify  the  current  shape  of  a 
polygon  mesh  being  dealt  with  so  that  it  can  be  handled 
efficiently. 

There  are  three  shapes  of  mesh  each  corresponding  to  a class 
of  polyhedra.  The  first  mesh  shape  is  the  nonclosed  polyhedra 
or  open  mesh.  The  second  shape  is  the  closed  concave 
polyhedral  mesh.  The  third  shape  is  the  closed  convex 
pol yhedr  a . 
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The  current  polygon  iresh  shape  in  effect  when  the 
SET_PGLYGCN_  MESH  command  is  invoked  determines  the  shape 
attribute  of  that  iresh. 

The  current  polygon  mesh  shape  in  effect  when  the 
SET_POLYGON_MESH  command  is  encountered,  determines  the  shape 
attribute  of  that  mesh. 

Default  — The  default  shape  is  a nonclcsed  polyhedra, 
an  open  mesh. 

Errors: 

1.  No  view  surface  selected. 

2.  No  segment  open. 

3.  Invalid  attribute  value. 


4. 2. 1.2  INTEFROGATING  CURRENT  ATTRIBUTE  VALUES  FOR 
STATIC  PRIMITIVE  ATTRIBUTES 

4. 2. 1.2.1  INCUIRE_CURRENT_PCLYGON_TYPE  (TYPE) 

This  function  returns  the  current  polygon  type  attribute. 

Errors: 

None . 


4. 2. 1.2. 2 INCUIRE_CURRENT_COLCR 
INQUIRE_CURRENT_COLOR  (R,G,B) 

Returns  the  current  color  attribute  in  R,G,B.  R,G,E  are  in 
the  range  of  0,1. 

Er ror s : 

1.  No  view  surface  is  selected. 

2.  Type  of  the  selected  view  surface 
is  gray  level  rather  than  color. 


INCUI RE_CUPRFNT_INTENSITY  (INTENSITY) 

Returns  the  current  intensity  attribute.  INTENSITY  range  is 
between  0,1. 

Errors : 

1.  No  view  surface  is  selected. 

2.  Type  of  the  selected  view  surface 
is  color  rather  than  gray  level. 


INCUI PE_CURRENT_COLOR_ INDEX  (I) 

Returns  the  index  of  the  current  color. 
Er ror s : 

1.  No  view  surface  is  selected. 

2.  Type  of  the  selected  view  surface 
is  gray  level  rather  than  color. 


INOUIRE_CURRENT_INTENSITY_INDEX  (I) 

Returns  the  inrlex  of  the  current  intensity. 


Errors: 

1.  No  view  surface  is  selected. 

2.  Type  of  the  selected  viev  surface 
is  color  rather  than  gray  level. 


4. 2. 1.2. 3 INCUIRE_VERTEX_COiXRS 

1NQU1RE_VERTEX_C0L0RS  ( R_APPAY , G_ARRAY , B_ARRAY , N) 
INQUIK£_VERTRX_INTRNSITIES  ( INTENSI1 Y_ARRAY , N) 

This  function  returns  the  colors  (intensities)  of  the 
vertices  of  the  current  shaded  polygon  set  by  the  SET_VERTEX 
command.  R,C,B's  (intensities)  are  in  the  range  of  0,1. 

Er  ror  s : 

1.  No  view  surface  is  selected. 

2.  N < =2  . 

3.  Type  of  selected  view  surface  is  gray  level  rather  than 
color,  or  vice  versa. 
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INCUI RE  VERTEX_COLORE  BY  INI  FX  ( INDEX_APRAY , N) 

INCUI RE_VEKTEX_INTEKS IT1 EU_ry_ INC FX  ( INDEX_AKRAY , N) 

This  function  returns  the  irdices  of  the  colors  (intensities) 
of  the  vertices  of  the  current  shaded  polygon  set  by  the 
SLT_VtKTEX  coirirand. 

Errors : 

1.  No  view  surface  is  selected. 

2 . N < =2  . 

3.  Type  of  selected  view  surface  is  gray  level  rather  than 
color,  or  vice  versa. 
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4. 2. 1.2. 4  INCUIRE_PIXEL_A.REAY  ( ACTIVE_FLAG , COLUMNS,  ROWS,  ARRAY) 

This  function  returns  the  log ical  var i able  ACTIV£_FLAG.  If  it 
is  set  to  true  then  the  current  pixel  array  and  its 
oimensions  are  returned.  If  it  is  false  then  the  pixel  array 
will  be  stored  in  a file  (see  INCUIRE_P1XEL_FILE) . 

! Errors: 

None . 


4. 2. 1.2. 5  1NCUIKE_PIXEL_FILE  ( ACTIVE_FLAG  .COLUMNS  , ROViS  , 

FILE_NAME) 

This  function  returns  the  logical  variable  ACTIVE_FLAG.  If  it 
is  set  to  true  then  current  file  name  and  its  dimensions  are 
returned.  If  it  is  false  then  the  pixel  array  will  be  stored 
in  an  array  (see  INCUIRE_PIXEL_ARPAY) . 

Errors: 

None . 


4. 2. 1.2. 6  INCUIRE_PIXEL_ARRAY_FXTENT  (X_LENGTH , Y_LENGTH) 

This  function  returns  the  current  pixel  array  extent 
information . 

Errors: 

None . 


J 4. 2. 1.2. 7 INQGIRE_VERTEX_NAP  ( VERT EX_INDEX_AREAY , X_NAP , Y_MAP) 

This  function  returns  the  current  vertex  map  information. 

Er  ror  s : 

None . 


4. 2. 1.2. 8 INOUIRE_CUPRENT_POLYCCN_NFSH_SHAPE  (SHAPE) 

This  function  returns  the  current  polygon  mesh  shape 
at  t r i bute  . 

Errors: 

None . 


4. 2. 1.3  REDEFINING  ATTRIEUTE  VALUES  FOR  STATIC 
PRIMITIVE  ATTPIBUTES 

REDEFINE_COLOR  (R,G,B  , R'.G'.B') 

All  output  primitives  displayed  on  the  selected  view  surface 
with  color  of  R,C,E  will  be  changed  to  have  the  color  of 
R' ,G* ,B ' . Both  F,G,B  and  R'^G'/E'  are  rounded  by  the  core 
system  to  the  nearest  color  displayable  on  the  currently 
selected  view  surface.  If  the  current  color  attribute  value 
is  R,G,B,  it  is  also  changed  to  P'jG'fB'. 

Errors : 

1.  No  view  surface  is  selected. 

2.  Invalid  attribute  value. 

3.  Type  of  the  selected  view  surface 
is  gray  level  rather  than  color. 


RLDEF  INE_COLGK_INr>r  X (I,R,G,E)  1 <=  I <=  N 

This  function  changes  the  color  value  whose  index  is  I to 
K,G,u.  The  R,G,B  is  rounded  by  the  core  system'  to  the 
nearest  color  displayable  on  the  currently  selected  view 
surface.  If  the  value  of  the  current  color  attribute  has  the 
index  of  I,  then  the  current  color  attribute  is  also  changed. 

Errors: 

1.  No  view  surface  is  selected. 

2.  Invalid  color  index. 

3.  Invalid  color  attribute  value. 

4.  Type  of  the  selected  view  surface 
is  gray  level  rather  than  color. 


REDEF INE_INTENSITY  (INTENSITY,  NEW_INTENSITY) 

All  output  primitives  displayed  on  the  selected  view  surface 
with  intensity  of  INTENSITY  will  be  changed  to  have  the  an 
intensity  of  NEW  INTENSITY.  Both  INTENSITY  and  NEW_ INTENSITY 
are  rounded  by  tITe  core  system  to  the  nearest  intensity 
displayable  on  the  currently  selected  view  surface.  If  the 
current  intensity  attribute  has  a value  of  INTENSITY,  it  is 
also  changed. 

Errors: 

1.  No  view  surface  is  selected. 

2.  Invalid  attribute  value. 

3.  Type  of  the  selected  view  surface 
is  color  rather  than  gray  level. 
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FEDEFINE_INTENSITY_INDF  X (I,  INTENSITY) 

This  function  changes  the  intensity  value  whose  index  is  I to 
INTENSITY.  The  INTENSITY  is  rounded  by  the  core  system  to 
the  nearest  intensity  displayable  on  the  currently  selected 
view  surface.  If  the  value  of  the  current  intensity 
attribute  has  the  index  of  I,  then  the  current  intensity 
attribute  is  also  changed. 

Errors: 

1.  No  view  surface  is  selected. 

2.  Invalid  intensity  index. 

3.  Invalid  intensity  attribute  value. 

4.  Type  of  the  selected  view  surface 
is  color  rather  than  gray  level. 
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7 CONTROL 


7.2  FUNCTIONAL  CAPABILITY 

7.2.2  DEVICE  SELECTION 

7. 2. 2. 2 SELECTING  THE  VIEW  SUFFACE 

7. 2. 2. 2.1  SELECT_VIEW_SUFFACE  (SURFACE_NANE .COLOR) 

This  function  selects  the  logical  view  surface  SUFFACF_NAME 
for  all  subseouent  graphic  output,  until  the  view  surface  is 
deselected  with  a DESELFr'T_VIFW_SUFFACE  functional  call.  The 
COLOR  parameter  specifier  whether  the  view  surface  is  used 
to  display  intensities  (P'ac k and  White) , or  color  (Red, Green 
.Blue) . 

Errors: 

1 . The  spec ified  surface  has  not  been  initial! zed . 

2.  The  specified  surface  is  already  selected. 

3.  The  specified  surface  was  not  selected  (because  of 
resource  1 lmi tat  ions , for  example). 

4.  A segment  is  open. 

5.  View  surface  is  not  capable  of  displaying  color. 

6.  Invalid  COLOR  parameter 

7.2.7  BATCHING  OF  UPDATES 

7. 2. 7. 2 ENDING  A LATCH  OF  UPDATES 

7. 2. 7. 2.1  BATCHING  OF  UPDATES 
END_  EATCK_CF_UPDATE  (ACTION) 

This  function  denotes  the  end  of  a batch  of  changes  to  the 
picture.  All  changes  to  the  picture  that  are  specified  prior 
to  this  function  call  are  guaranteed  to  have  taken  place 
before  control  returns  from  this  function.  This  function  can 
be  invoked  at  any  time  after  a EEGIN_EATCH  function  call. 
ACTION  is  a logical  variable  indicating  if  a newtrame 
action  should  be  performed. 

tr  ror  s : 

1.  There  is  no  BEGIN  BATCH. 


7.2.9  BACKGROUND  COLOR  OR  INTENSITY 


7. 2. 9.1  SETTING  THE  BACKGROUND 

SET_BACKGROUND_COLOR  (R,G,B) 

SET_BACKGROUND_INTENSITY  ( INTENSITY) 

The  global  background  color  (intensity)  is  set  to  R,G,B 
(INTENSITY).  This  action  does  not  take  effect  until  a 
newfran.e  action  occures. 

Errors: 

1.  Attribute  value  out  of  range. 


SET_BACKGROUND_COLOR_ INDEX  (INDEX) 
SET_BACKGROUND_INTENSITY_INDEX  ( INDEX) 

The  global  background  color  (intensity)  is  set  to  the  color 
(intensity)  with  the  index  of  INDEX.  This  action  does  not 
take  effect  until  a newfraire  occures. 

Errors: 

1.  Attribute  index  out  of  range. 


7. 2. 9. 2 INQUIRING  WHAT  THE  BACKGROUND  IS 

I NQU I PE_EACKGPOUND_COLOR  (R ,G , B) 

INQUIRE_EACKGROUND_INTENSITY  (INTENSITY) 

Returns  the  value  of  the  global  background  color  (intensity) 

Errors : 

None . 


INQUIRL_BACKGROUND_COLOR_INDEX  (INDEX) 
INQUIRE_BACKGRGUND_INTENSITY_INDEX  ( INDEX) 

Returns  the  index  of  the  global  background  color  (intensity) 


7.2.10  INQUIRING  COLORS  AND  INTENSITIES 


7.2.10.1  INQUIRING  THE  NUMBER  OF  COLORS  OR  INTENSITIES 
INQUI RE_NUMBER_OF_COLORS  (N) 

Reports  the  number  of  colors  which  can  be  displayed 
simultaneously  on  the  currently  selected  view  surface.. 

Er  ror s : 

1.  No  view  surface  is  selected. 

2.  Type  of  the  selected  view  surface 
is  gray  level  rather  than  color. 


INCUIRE_NUMBER_OF_INTENSITIES  (N) 

Reports  the  number  of  intensities  which  can  be  displayed 
simultaneously  on  the  currently  selected  view  surface. 

Errors : 

1.  No  view  surface  is  selected 

2.  Type  of  the  selected  view  surface 
is  color  rather  than  gray  level. 


7.2.10.2  INQUIRING  THE  VALUE  OF  COLOR  OR  INTENSITY 

INQUIRE_COLOR_VALUE  (I,R,G,E)  1 <=  I <=  N 

Reports  the  value  of  color  I (in  K,G,B)  of  the  currently 
selected  view  surface.  R,G,B  are  in  the  range  of  0,1. 

Errors : 

1.  No  view  surface  is  selected. 

2.  I is  out  of  range  (Less  than  1 or 
greater  than  N) . 

3.  Type  of  the  selected  view  surface 
is  gray  level  rather  than  color. 


INCUIPE_INTF.NSITY_VALUF  (I,  INTFNSITY)  1 <=  I <=  N 

Reports  the  value  of  intensity  I of  the  currently  selected 
view  surface.  INTENSIT Y is  in  the  range  of  0,1. 

Errors: 

1.  No  view  surface  is  selected. 

2.  1 is  out  of  range  (Less  thar  1 or  greater 
than  N)  . 

3.  Type  of  the  selected  view  surface 
is  color  rather  than  gray  level. 


7.2.11  INQUIRING  GLOBAL  COLORS  AND  INTENSITIES 

7.2.11.1  INQUIRING  THE  NUMBER  OF  GLOBAL  COLORS  AND  INTENSITIES 

INQUIRE_NUMBER_OF_CLOBAL_COLORS  (M)  M >=  N 

This  function  returns  the  total  nuirber  of  colors  which  can  be 
displayed  on  the  currently  selected  view  surface.  It  is  not 
necessary  that  all  the  colors  be  simultaneous! y displayable. 

Errors: 

1.  No  view  surface  is  selected. 

2.  Type  of  the  selected  view  surface 
is  gray  level  rather  than  color. 


INQUIRL_NUMEER_OF_GLCBAL_INTENSITIES  (M)  M >=  N 

This  function  returns  the  total  number  of  intensities  wich 
can  be  displayed  on  the  currently  selected  view  surface.  It 
is  not  necessary  that  all  of  the  intensities  be 
simultaneously  displayable. 

Errors: 

1.  No  view  surface  is  selected. 

2.  Type  of  selected  view  surface 

is  color  rather  than  gray  level. 


7.2.11.2  INQUIRING  THE  VALUE  OF  CtOBAI,  CCLOP  AND  INTENSITY 

INQUIRE_GLOEAL_COLCP  (I,R,G,E)  1 <=  I <=  M 

Returns  the  value  of  color  I (in  F,G,B)  from  the  set  of  all 
colors  (Global)  for  the  currently  selected  view  surface. 
R,G,E  are  in  the  range  of  0,1. 

Errors: 

1.  No  view  surface  is  selected. 

2.  I is  out  of  range  (Less  than  1 or 
greater  than  N) . 

3.  Type  of  the  selected  view  surface 
is  gray  level  rather  than  color. 


I NQU I RL_GLCEAL_ INTENSITY  (I,  INTENSITY)  1 <=  I <=  M 

Returns  the  value  of  intensity  I from  the  set  of  all 
intensities  (Global),  for  the  currently  selected  view 
surface.  INTENSITY  is  in  the  range  of  0,1. 

Errors: 

1.  No  view  surface  is  selected. 

2.  I is  out  of  range  (Less  than  1 or 
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greater  than  M) . 

3.  Type  of  the  selected  view  surface 
is  color  rather  than  gray  level. 


7.2.12  DISPLAY  MODE 

7.2.12.1  SET_DISPLAY_MODE  (MODE) 

This  function  sets  the  display  mode  to:  (1)  Fast  mode:  Draw 
only  the  contour  of  the  polygons  or  surrounding  boundary  of 
the  painted  polygon.  No  hidden  surface  or  lines  are  removed. 
(2)  Hidden  line  mode:  Hidden  lines  are  removed.  Processing 
is  done  only  when  END_BATCH  occures.  (3)  Hidden  surface 
mode:  Hidden  surfaces  are  removed.  Processing  is  done  only 

when  END_EATCH  occures. 

Errors : 

1.  System  is  not  initialize”3. 

2.  No  view  surface  is  selected. 

3.  Invalid  mode  value. 


7.2.12.2  INCUIKE_DISPLAY_MODr  (MODE) 

This  function  returns  the  display  mode,  (see  SET_DISPLAY_MODE 
(MODE) ) . 

Errors: 

None . 


7.2.13  PIXEL  AFRAY  FORMATTING 

7.2.13.1  SET_PIXEL_ARRAY_FORMAT  ( BITS_PER_PI XEL , BITS_PER_PACK ING_UN IT , 

PIXELS_PER_UN IT) 

This  function  is  used  to  specify  the  storage  format  in  which 
a pixel  array  (or  file)  will  he  passed.  The  EITS_PER_PIXEL 
value  tells  how  many  bits  are  designated  to  represent  each 
pixel.  The  E ITS_PER_PACK I NG_LN IT  gives  the  basic  word  length 
that  the  information  will  be  placed  in  (it  will  usually  be 
8, 12, or  16  bits).  The  PIXEI  S_PFP_l,NIT  value  tells  how  manv 
pixel  descriptions  will  be  placed  in  each  packino  unit.  The 
packing  is  assured  to  be  right  justified. 

Defaults  — There  are  none. 

Errors: 

1.  Invalid  attribute  value. 
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i 7.2.12.2  INOUIFE_PIXEL_AFRAY_FOFMAT  (SET_FLAG ,BITS_PEF_PIXEL , 

BITS  PEP  PACKING_UNIT,PIXELS_PEF_UNIT) 

I 

This  function  returns  the  logical  variable  SET_FLAG  that 
tells  if  the  pixel  array  format  has  been  set.  If  it  is  set  to 
true  then  the  current  pixel  array  format  information  is 
returned . 

Errors: 

j None. 
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10.2.1  WRITING  A VIEW  SUFFACE  PIXEL 

WPITE_V I FW_SURFACC_P I XEL_INTENS ITY  (X,  Y,  INTENSITY) 

WRITE_VI  EW_SUP.FACE_PIXEL_COLOF  ( X , Y , F , G , E ) 

The  intensity  or  color  of  the  pixel  on  the  currently  selected 
view  surface  addressed  by  X,Y  (in  normalized  device 
coordinates)  overwrites  the  INTENSITY  or  F,G,E.  The  INTENSITY 
or  R,G,E  is  rounded  by  the  core  system  to  the  nearest 
intensity  or  color  displayable  on  the  currently  selected  view 
surface.  INTENSITY  and  P.,G,E  are  each  between  0,1. 

Er  ror  s : 

1.  No  view  surface  is  selected. 

2.  No  segment  is  open. 

3.  X , Y out  of  range. 

4.  Intensity  or  color  attribute  out  of  range. 

5.  Type  of  the  selected  view  surface  is  gray  level  rather  than 
color,  or  vice  versa. 


V<KITE_V  I EW_SURF  ACt_l  IXEL  INTENSITY  BY_1NDEX  (X,Y,  INDEX) 

l.KITE_VIEW_SURFACE_PIXEL_CGLOR_EY_lNDEX  (X,Y,  INDEX) 

The  intensity  or  color  of  the  pixel  on  the  view  surface 
addressed  by  X,Y  (in  normalized  device  coordinate)  overwrites 
the  intensity  or  color  referenced  by  index  INDEX. 

Errors : 

1.  No  view  surface  is  selected. 

2.  No  segment  is  open. 

3.  X or  Y out  of  range. 

4.  INDEX  out  of  range. 

■b.  Type  of  selected  view  surface  is  gray  level  rather  than 
color,  or  vice  versa. 

10.2.2  READING  A VIEW  SURFACF.  FIXEL 

PEAD_VIFW_SURFACE_PIXEL_INTENSITY  (X ,Y , INTENSITY) 

KLAD_VI  LV,_SUPFACL_P1  XEL_COLOR  ( X , Y , R ,C  , E ) 

Reports  the  intensity  or  color  in  Red,  Green,  and  blue 
components,  of  the  Pixel  addressed  by  X,Y  (in  normalized 
device  coordinates)  on  the  currently  selected  view  surface. 

t.i  ror  s : 

1.  No  view  surface  is  selected. 

2.  X or  Y out  of  range. 

3.  Type  of  the  selected  view  surface  is  gray  level  rather  than 
color,  or  vice  versa. 
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READ  VIEW  SURFACE_PIXEL_INTENSITY_BY_INDEX  (X,Y, INDEX) 
READ~VIEW~SURFACE_PIXEL_COLOR_BY_INDEX  (X,Y, INDEX) 

Reports  the  intensity  or  color  index  of  the  pixel  addressed 
by  X , Y (in  normalized  device  coordinate)  on  the  currently 
selected  view  surface. 

Errors: 

1.  No  view  surface  is  selected. 

2.  X or  Y out  of  range. 

3.  Type  of  the  selected  view  surface  is  gray  level  rather  than 
color,  or  vice  versa. 


10.2.3  WRITING  A CROUP  OF  VIEW  SURFACE  PIXELS 

WRITE_VIEW_SURFACE_PIXELS_INTENSITY_BY_INDEX 

(XNIN  , XNAX , YMIN , YMAX) 
WRITE_VIEW_SUKFACt_PIXELS_COLOF_EY_INDEX 

(XMIN , XNAX , YMIN , YMAX) 

writes  the  intensity  or  color  of  pixels  from  the  current 
pixel  array  into  the  specified  region  of  the  selected  view 
surface, using  the  pixel  array  packing  format.  If  the  array 
is  a file,  then  the  file  is  overwritten  into  the  specified 
portion  of  the  view  surface.  The  size  of  the  current  pixel 
array  (xmax-xmin  and  ymax-ymin)  must  be  the  same  as  the  size 
(xmax-xmin  and  ymax-ymin)  of  the  specified  portion  of  the 
view  surface.  Current  pixel  array  can  be  set  by  calling  the 
SET_  CUKRENT_PIXEL_AKRAY  function.  Intensities  or  colors  are 
specified  by  their  indices. 

Errors : 

1.  No  view  surface  is  selected. 

2.  Xmin  >=  Xmax . 

3.  Ymm  >=  Ymax. 

4.  Xmin ,Xmax ,Ymi n or  Ymax  out  of  range. 

5.  The  current  pixel  array  is  too  large  or  too  small. 

6.  Type  of  the  selected  view  surface  is  gray  level  rather  than 
color,  or  vice  versa. 


71 


LJ1 


I 

i 

i 

| 


j 


10.2.4  READING  A GROUP  OF  VIEW  SURFACE  PIXELS 

READ  VIEW  SURFACE  PIXELS  INTENS1TY_BY_INDEX 
~ " (XMIN ,XMAX, YMIN , YMAX) 

READ  VIEW  SURFACE_PIXELS_CGLGR_BY_INDEX 

( XMIN ,XKAX, YMIN, YMAX) 

Reads  the  intensity  or  color  of  the  specified  region  of  the 
selected  view  surface,  into  the  current  pixel  array,  using 
the  pixel  array  packing  format  specified  by  SET_PIXEL_ARRAY 
_FORMAT.  If  the  array  is  a file  then  the  specified  portion 
of  the  view  surface  is  written  into  the  file.  The  size  of 
the  current  pixel  array  (xmax-xuin  and  ymax-ymin)  must  be 
the  same  size  (xmax-xmin  and  ymax-ymin)  of  the  part  of  the 
view  surface  being  interrogated.  This  array  is  available  by 
calling  the  INOUIFE_CUPRENT_PIXEL_ARFAY.  Intensities  or 
colors  are  specified  by  their  indices. 

Errors : 

1.  No  view  surface  is  selected. 

2.  Xirin  >=  Xmax. 

3.  Ymin  >=  Yirax. 

4.  Xmin , Xmax  , Ymin  or  Ymax  out  of  range. 

5.  The  current  pixel  array  is  too  large  or  too  small. 

6.  Type  of  the  selected  view  surface  is  gray  level  rather  than 
color,  or  vice  versa. 


10.2.5  SET_VIEW_SURFACE_CVEELAY_KODE  (MODE) 

This  function  specifies  how  a new  pixel  will  affect  the  old 
pixel  on  the  view  surface.  A new  pixel  is  one  which  is  sent 
by  either  a SET_VIEW_SURFACE_FIXFL  or  in  a SET_VIEW_SUPFACE 
_PIXELS  function.  An  old  pixel  is  one  which  already  exists 
or.  the  view  surface. 

The  particular  way  the  new  pixel  combines  with  the  old  is 
controlled  by  the  MODE.  A partial  list  of  modes  is:  REPLACE, 
AND,  OR,  EXCLUSIVE  OP,  ADD,  SUBTRACT,  .... 

Default  — The  default  mode  is  FEPI.ACF. 

Lr  r or  s : 

1.  No  view  surface  is  selected. 

2.  No  segment  is  open. 

3.  Nonraster  view  surface  is  selected. 

4.  Invalid  mode  value. 


10.2.6  IN’CUl  RE_V  I EV._SUPFACE_OVERLAY_MODE  (MODE) 

This  function  returns  the  current  vaue  of  the  overlay  mode, 
which  either  has  the  initial  cefauit  value  or  has  been  set  by 
BE1_VIEW_SUFFACE_0VERLAY_MCEE. 

Errors: 

None . 


PART  IV:  MODIFICATIONS  TO  EXTEND  A VECTOR  GRAPHICS 
SYSTEM  TO  A RASTER  GRAPHICS  SYSTEM 


What  follows  is  a list  of  modifications  and  additions 
that  we  are  making  to  the  original  line  drawing  Core  Graphics 
S-  stem  to  allow  it  to  handle  raster  graphics.  An  explanation 
of  the  concepts  and  functions  needed  is  in  the  paper  "Raster 
Graphics  Extensions  to  the  Core  Graphic  System" , and  in  the 
reference  manual  for  those  extensions. 

The  list  given  here  outlines  the  software  needed  to 
support  this  expansion.  The  Core  System  at  George  Washington 
University  is  being  expanded  in  this  way,  so  many  features 
have  already  been  implemented.  Those  features  that  have 
not  yet  been  implemented  are  marked  by  an  astrisk. 

We  provide  this  list  with  the  hope  that  it  will  be 
useful  to  others  who  undertake  similar  efforts  either 
with  the  Core  System  or  with  other  graphics  packages. 

1.  Device  Driver  Extensions 

1.  A software  scan  line  converter,  if  no  hardware 
scan  converter  is  available. 

2.  Add  color  and  intensity  levels 

3.  A way  of  specifying  if  color  or  gray  scale  is 
being  used 

4.  Allow  the  Device  Driver  to  accept  3D  normalized 
device  coordinates. 

5.  Allow  the  Device  Driver  to  deal  with  a modularized 
Pseudo  Display  File  (see  section  3) 

6.  A polygon  scan  converter 

*7.  A more  direct  way  to  output  a pixel  array  to  the 
screen. 
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2.  General  Extensions 

1.  Add  a way  to  set  the  background  color  or  intensity 

2.  Add  a new  set  of  display  inodes: 

a.  Fast  Mode 

b.  Hidden 

c.  Hidden  Line  Removal  Mode 

3.  Create  a general  subroutine  to  control  where  information 
should  be  sent  (Device  Driver  or  Pseudo  Display  File) . 
This  was  added  to  support  the  three  display  modes  and 

to  further  structure  the  code. 

*4.  Either  a simple  2JaD  depth  priority  sort  or  a complete 
Hidden  Surface  Removal  Algorithm. 

*5.  Add  direct  pixel  (view  surface)  operations 

3.  Pseudo  Display  File  (PDF) 

1.  Add  a Z component  to  each  vertex  coordinate  in  the 
PDF.  This  is  required  for  the  Hidden  Surface  Removal 
Algorithm  (HSA)  in  Normalized  Device  Coordinate  (NDC) 
space. 

2.  Add  opcodes  for  the  Polygon  and  its  attributes 

3.  Modularize  the  PDF.  This  means  that  all  the  coordinate 
information  for  an  output  primitive  (Line,  Text,  Polygon) 
is  grouped  together,  when  stored  in  PDF.  For  example, 

a line  definition  would  consist  of  the  following  in 
the  PDF:  the  opcode  and  the  coordinate  of  both  vertex 
coordinates.  Before  the  PDF  was  made  modular,  a line 
definition  would  only  contain  one  raster  coordinate, 
the  other  vertex  would  be  found  in  either  a move, 
mark,  or  line  definition  made  before  the  lines  endpoint 
was  given.  This  made  the  task  of  any  Hidden  Line/Surface 
Removal  difficult,  because  a search  had  to  be  made 
to  find  the  starting  point  of  the  line. 

*4.  The  data  structure  of  the  PDF  could  be  further  deve- 
loped to  support  Hidden  Surface  Removal  Algorithm. 

The  specific  way  of  structuring  the  PDF  will  depend 
on  the  type  of  Hidden  Surface  Algorithm  that  is  being 
used. 

*5.  Allow  the  PDF  to  reference  pixel  array  files.  Complex 
images  require  very  large  pixel  arrays  (512X512) , 
therefore  it  is  important  to  avoid  storing  them 
inside  of  the  PDF.  The  pixel  array  should  instead 
be  stored  in  a separate  file,  and  the  file  reference 
information  placed  in  the  PDF. 

4.  Viewing  Primitives 

1.  Pass  the  Z components  along  with  the  X,Y  coordinates 
for  output  primitives  (] ine , text , etc . ) to  the  PDF. 

2.  Make  3D  windows  (truncated  pyramids  for  perspective 
views)  map  into  rectangular  boxes  in  3D  Normalized 
Device  Coordinates.  This  must  be  done  so  that  a 
line  in  the  world  coordinates  remains  a straight  line 
in  NDC  space. 
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3.  Send  all  the  vertex  coordinates  that  describe  a 

| primitive  (line,  text,  etc.)  in  a group  to  allow  a 

modularized  PDF  to  be  constructed. 

4.  Add  the  basic  polygon  primitives  and  the  required 
support: 

a.  Add  the  user  output  primitive  calls. 

b.  Apply  the  viewing  transformations  for  the  vertices 
of  a polygon. 

c.  Calculate  additional  information  like  the  minimum 
Z coordinate  and  the  equation  of  the  plane  con- 
taining the  polygon.  This  is  passed  to  the 

1 PDF  to  make  the  hidden  surface  algorithm  more 

efficient. 

*5.  Add  a polygon  clipping  algorithm. 

6.  Painted  Polygon  extensions: 

a.  A new  set  of  polygon  primitive  attributes. 

*b.  A method  for  mapping  a section  of  an  image  onto 
a polygon  in  the  world. 

*c.  The  translation,  scaling,  and  rotation  of  images 
*d.  An  averaging  or  convolution  algorithm  used  to 
maintain  the  appearance  of  an  image  (minimize 
the  distortion  caused  by  the  above  transformations) 

7.  Shaded  Polygon  extensions: 

*a.  The  SET_VERTEX_COLORS  attributes 
*b.  The  color  interpolation  algorithm  for  GOURAND 
shading 

4.  Mesh  Extensions 

*a.  The  mesh  vertex  list  - primitive 
*b.  The  POLYGON_EDGE_LIST  subroutine. 

5.  Attributes 

1.  Extensions  of  the  color  and  intensity  specifi- 
cations 

a.  Color/Intensity  defined  by  index 
*b.  Color/Intensity  defined  by  value  (Red,  Green, 
Blue) 

*c.  A method  for  finding  the  best  color  fit  for 

a particular  device  from  an  R,G,B  specification. 
*d.  A set  of  functions  for  redefining  colors 
referenced  by  index 

*e.  Extend  the  color/intensity  inquiry  capabilities. 

2.  Add  the  Polygon  type  attribute 

3.  The  Mesh  shape  attribute 

4.  A way  of  handling  pixel  arrays  and  files 
*5.  Painted  Polygon  attributes 

*6.  Shaded  Polygon  attributes 
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Raster  graphics  extensions  to  the  Graphics  Compatibility  System 
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WATERWAYS  EXPERIMENT  STATION 
REPORTS  PUBLISHED  ON  THE 
GRAPHICS  COMPATIBILITY  SYSTEM 


Title  Date 

1 Host-Computer  Implementation  Guidelines  for  the  Three-  Mar  1979 

Dimensional  Graphics  Compatibility  System  (GCS) 

2 Device  Implementation  Guidelines  for  the  Three-  Mar  1979 

Dimensional  Graphics  Compatibility  System  (GCS) 

3 Raster  Graphics  Extensions  to  the  Graphics  Compatibility  Mar  1979 

System  (GCS) 
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